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I. INTRODUCTION 


AS “SPLICE OVERY Tay 


The SPLICE (Stock Point Logistics Integrated 
Communications Environment) concept is a revolutionary 
methodology for integrating an online and real time network 
of distributed computer systems into the Navy Supply System. 
To date, true online interactive processing between hosts at 
two geographically separated stock points has not been 
achieved. Currently, the few transactions that socen 
between two geographically separate hosts are executed in 
batch mode. The most pressing enhancement that SPLICE will 
bring to the Navy Supply System is mainframe processor 
relief at the NSCs (Naval Supply Centers) and NSDs (Naval 
Supply Depots) which together comprise the major stock 
points. The objectives for SPLICE can be found in the 
SPLICE Functional Description [Ref. 1: pp. 2-2, 2-3] 7 ime 
will not be repeated here since they have been discussed at 


length in almost every other SPLICE related study. 


B. STOCK POINT MAINFRAME SATURATION 


Presently these Burroughs and Perkin-Elmer mainframes 
are saturated. It was felt that much could be done to 
alleviate the burden on these mainframes by installing front 
end processors to handle telecommunications processing and 
interactive queries from CRI (Cathode Ray Tube) terminalee 
These Burroughs and Perkin-Elmer machines are for the most 
part mid-size mainframes ranging from third generation to 
early fourth generation hardware. The hardware and 
operating systems employed in these machines are ‘geared for 


efficient batch operation but not interactive processes. 
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Interactive processing has been retrofitted into the 
operation of these machines. However, the cost in CPU 
(Central Processing Unit) resources has been expensive and 
terribly taxing to the system, much to the detriment of 
overall operations. The present suite of hardware located 
at the major stock points is not able to properly support 
inventory control, contract management, financial 
accounting, requisition processing, transportation 
management and other automated logistic operations while 


concurrently handling interactive CRT processes. 


eer LCE NEAR-TERM PAYOFF 


The short-term payoff from the SPLICE hardware is not 
amply im the function of front end processing for 
telecommunications traffic. The expected payoff is in 
replicating frequently queried files and connecting these 
replicated files directly to the SPLICE hardware. It is 
estimated that ninety percent of all interactive CRT 
processes transacted against the stock point mainframes are 
Simple queries. In this category of interactive processing, 
a question is asked of a file, but no records are changed, 
added or deleted. In other words, the file is not affected 
by the query, the users simply want to look at some 
pertinent records. Queries will be satisfied by duplicate 
files which are mirror images of the Burroughs or 
Perkin-Elmer files, on disk drives directly connected to 
SPLICE hardware. In this manner ninety percent of the CRT 
transactions can be handled by SPLICE hardware. This would 
obviate the need to access files on disk drives connected to 
the mainframes. Hence, a drastic reduction in CRT 


memset LOns executed on these mainframes should result. 
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D. SPLICE LONG-TERMera rol 


SPLICE long-term effectiveness and efficiency 1S 


outlined by the major categories that follow [Ref. 2: ple 
1. Telecommunications Support 


SPLICE will establish a nucleus for Supporting jam 
present and future Navy logistic data communications 
requirements. Local data communications will be handled 
through a local area network. Long haul data communications 
will be provided through connection to the DDN (Defense Data 
Network). All of the SPLICE local area networks will be 
connected together, using the DDN as a backbone of one large 
virtual SPLICE network. 


2. Interactive and Distributed Processing Support 


The present mainframe hardware suite is not geared 
for interactive and distributed processing. The 
implementation of redundant front end multiprocessors for 
the current suite of mainframes will provide fault tolerance 
and graceful degradation of processing. These front end 
multiprocessors will handle all telecommunications 
processing and management of the local area network. They 
will act as the local gateway into the DDN for long haul 
data communications and manage the long haul process to 


process interfaces. 


3. Economic Advantages of Hardware Standardization 


Presently there exists a proliferation of various 
minicomputers that serve as front end processors for various 
functions to the Burroughs and Perkin-Elmer mainframes. 
These minicomputers are in varying stages of obsolescence 
and for the most part are incompatible with each other. 


Implementation of SPLICE multiprocessor hardware will 
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replace these obsolete and incompatible front end 
processors. This will reduce the cost of supporting 
multiple versions of hardware and software as well as reduce 


the personnel required for these operations. 


Eee RESEARCH OBJECTIVE 


The major concerns of this research are the long-term 
payoffs identified in the previous section. Specifically 
this involves telecommunication support, interactive 
processing support and distributed processing support. 
Implementation of these objectives must be done in a way so 
that it is not obvious to the user that complex processes 
must be invoked to effect desired communications and 
transactions. This must be achieved in an intra-SPLICE 
environment, as well as with networks and processes residing 
outside the topology of SPLICE. A comprehensive data 
communications plan and concomitant protocols must be 
implemented to bring these objectives to fruition. This 
research will attempt to solidify the groundwork for this 


plan and its required protocols. 


lye, 


II. SPLICE DEVELOPMENT BACKGROUND 


Several things have changed since the SPLICE Functional 
Description [Ref. 1] and System Specification [Ref. 3] were 
drafted. Some of these changes and their ramifications are 


discussed 1m -€his  enapreer. 


A. DEFINISIONS 
1. SPLICE Node 


In this document, a "SPLICE node" refers to the 
array of Tandem NonStop TXP multiprocessors and the 
HYPERchannel local area network that comprise the backbone 
telecommunications hardware for each SPLICE installation. 
These hardware facilities are described below. The reason 
for reference to each SPLICE system hardware complex as a 
"node" is due to packet switched network parlance. A ‘node" 
roughly equates to a computer or system of computers located 
at one geographical location within the larger context of a 
long haul packet switched network. Strictly speaking, a 
"node" is a point of a network generally containing a 
Switching element used to connect traffic, where various 


links come together [Ref. 4: p. 360]. 


2. Host 


When referring to a software application process 
that 1s resident and executing on a CPU (Central Processing 
Unit), the machine running the application process is often 
referred to as a "host." Sometimes the words “host" and 
"node" are used interchangeably when-referring to two 
machines at two geographically separate locations that are 


connected to each other over the long haul packet switched 
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mewoeric. A more formal definition of a "host" is a 
Somereecctlon OL Nardware and software which is attached to a 
network and uses that network to provide interprocess 


Communication and user services [Ref. 4: p. 352]. 


B. SPLICE CONTRACT AWARD 


The SPLICE contract was awarded on 17 November 1983 
Ieee 5: p. lj]. It covers a time span of 15 years. The 
Beeential total amount of this contract is $548,380,876. 
The minimum implementation of this contract covers the 
installation of SPLICE hardware and software interfaces at 
Eimewty-five sites. This contract has the potential for 
acquisition and implementation of sixty-two SPLICE nodes in 
the event that funding and needs of the Navy warrant the 
@e@awtional installations [Ref. 6: p. 5-1]. 


1. Prime Contractor (Federal Data Corporation) 


Federal Data Corporation is the prime contractor for 
SPLICE. They are responsible for the implementation and 
enforcement of standards for this large contract. They have 


subcontracted other corporations cited below to effect this. 
2. Hardware Subcontractor (Tandem Corporation) 


The Tandem Corporation is the prime subcontractor 
for SPLICE. Their main contribution is the SPLICE hardware, 
which is the Tandem NonStop TXP computer system. A 
Summarization of salient features of this hardware system 
meenwcited in Tandem literature [Ref. 7: pp. 1, 2]. 

Each Tandem NonStop TXP system includes at least two 
processor modules, multiple controllers, multiple data paths 
between CPUs and input/output controllers, and multiple 
power supplies [Ref. 7: p. 2-2]. There is built in 


redundancy in the system due to parallel controllers and 


ey 


parallel channels which facilitate dual paths and parallel 
flow of all information and data between CPUs and peripheral 
devices. All secondary storage devices are also parallel 
and redundant. Data is stored on two devices creating a 
mirror image of each other. Thus any single point of 
hardware failure will not stop an application process. The 
parallel channeling between CPUs is accomplished on Tandem's 
high speed DYNABUS interprocessor bus. There is a master - 
Slave relationship between each pair of processors in the 
Tandem NonStop TXP system. In actuality, this paired 
relationship is application dependent, not a physically 
designated setup. Any process that 1s resident and running 
on a system, Say system 1, is automatically backed up by its 
Slave paired system, say system 2. If any failure of the 
primary system 1S recognized by the backup slave system, the 
backup slave system takes over processing. Upon recognizing 
a hardware failure in system 1], the original slave 
processor, system 2, now becomes the master processor. 
System 2 will now attempt to designate another available 
functioning system to back ab Up as teco tae processor. 

Let us assume that system 5 1s up and eunmaaie soncees 
available to assume the duty as a slave processor for system 
2. System 5 now becomes the slave processor. In this 
manner, if system 2 should go down, then system 5, the new 
Slave, will be able to resume application processing without 
interruption. Thus for reasons of redundancy and backup, 
Tandem NonStop TXP systems are always installed in a 
configuration of from 2 to 16 machines. If more than 16 
machines are required, multiple banks of 2 through 16 more 
machines can be hooked together via Tandem Corporation's FOX 
fiber optic local area network. A Eypical ormmen 


configuration will consist of 6 or more CPUs. 
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Corporation) 


The Network Systems Corporation is the subcontractor 
for the local area network and attendant interfaces. They 
market a local area network product called HYPERchannel 
which is an HSLN (High Speed Local Network) implemented 
through a baseband bus [Ref. 8: pp. 143, 146, 163]. One of 
the main features of HYPERchannel is that it can achieve 
data transfer rates of up to 50 megabits per second. 
However, the most important feature of HYPERchannel with 
respect to SPLICE are the NIUs (Network Interface Units) 
that are implemented in the HSLN. These NIUs allow the 
interconnection of normally incompatible peripheral devices. 
The NIU transforms the data rate and protocol of the 
subscriber device to that of the local transmission medium 
and vice versa [Ref. 8: p. 208]. Through the use of these 
NiIUs, the HYPERchannel is able to connect a myriad of 
processors and peripherals, allowing them to interface with 
the Tandem NonStop TXP SPLICE hardware system. 


C. DEFENSE DATA NETWORK 


The DDN (Defense Data Network) is the mandated long haul 
data communications common switched network for the 
Department of Defense. A pressing need was seen for a data 
communications network that would enSure an adequate level 
of reliability and redundancy in wartime, as well as ensure 
Security of communications. The Department of Defense also 
sought to minimize the cost of rapidly expanding demand for 
data communications. AS a result of these requirements and 
the need to modernize, improve and consolidate smaller | 
existing data networks within the Department of Defense, the 


concept of the DDN was born. 


Ko 


1. Historical Perspective 


In 1969, DARPA (Department of Defense Advanced 
Research Projects Agency) initiated an R&D (Research and 
Development) program for a packet switched data 
communications network [Ref. 9]. This network was called 
the ARPANET. The original goal of the ARPANET was 
development of an experimental network whose purpose was to 
advance the state of the art in computer resource sharing. 
It was to develop a communications network and procedures 
that would allow dissimilar computers at different 
geographical locations to communicate with each other. 
Through this network, hardware, software and data resources 
could be shared conveniently and economically by a wide 
community of users. As the ARPANET matured and the initial 
R&D goals of the network were achieved, users with 
operational requirements began to proliferate. By 1975, the 
responsibility for the ARPANET was transferred from DARPA to 
DCA (Defense Communications Agency). This was done because 
of the size of the network, and the increase of operational 


vice experimental systems being implemented on the network. 
2. SWentsenon AULODNigw 


The Department of Defense has had a message switched 
data communications network operational for quite some time. 
This system is called AUTODIN. It is used heavily foreman 
text military message traffic. It is also uséd quite 
heavily by the military logistics community. Currently, the 
bulk of all MILSTRIP (Military Standard) Reqmas tao meanael 
Issue Procedure) transactions are transmitted through 
AUTODIN. Several years ago, it was recognized that the 
AUTODIN system was getting severely overloaded and had to be 
expanded or replaced. The system designated to enhance and 


replace AUTODIN. was called AUTODIN II. For several years an 
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effort was made in the direction of AUTODIN II 
implementation. However, DARPA's ARPANET project had proven 
to be so successful that strong arguments surfaced for 
implementation of a data communications system based on 
ARPANET's architecture. 

The assumptions under which AUTODIN II was planned 
were no longer valid in view of the changing requirements 
and costs. The small number of nodes planned for AUTODIN II 
were not deemed capable of Survival to a satisfactory degree 
in wartime. In addition, it was doubtful that the switches 
could be certified to handle traffic at all security levels. 
Finally AUTODIN II appeared to be too expensive. Also, the 
level of common carrier tariffs was increasing to the point 
as to make long access lines required for the limited number 
of nodes prohibitively costly. 

The AUTODIN II project got bogged down. Finally, on 
2 April 1982, the Deputy Secretary of Defense directed the 
PanODEN Ll project terminated [Ref. 10], [Ref. ll: 
bemetir, iv|. Furthermore, he instructed the Director of 
DCA to proceed immediately with the development of the 
Defense Data Network as outlined in the January 1982 ARPANET 


Replica Program Plan. 
3. Merging of Existing Networks into the DDN 


In 1983, DCA split the old ARPANET into two separate 
networks. As a result of the split, there is now an ARPANET 
for the research community and MILNET, an unclassified 
segment of the DDN, for the military community. In the near 
future, the MILNET, which is a spin off from the ARPANET, 
and the MINET (Movements Information Network), located in 
Europe, will be integrated into the MILNET to form the 
unclassified backbone segment of the~ DDN. 

The classified segment of the DDN is to be built on 
the foundation of the Secret Network. The WINCS (WIN 
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Communications Subsystem), SACDIN (Strategic Air Command 
Digital Network), DODIIS (Department of Defense Intelligence 
Information System) and TS will all eventually be integrated 


into the backbone of the Secret Network. 


4. Mandate for DDN as Dap s Long Haul Common Switched 


Data Network 


The following directives mandate implementation and 
use of the DDN as the common switched data communications 
network for the Department of Defense. In accordance with 
these directives, interconnection of long haul SPLICE nodes 
is to be accomplished through the DDN. Only by showing that 
the DDN is incapable of supporting the needs of SPLICE can a 
case be made for implementing an alternative long haul data 


communications arrangement. 


a. Deputy Secretary of Defense Memorandum of 2 
April WIG 2 


This document directed termination of AUTODIN II 
and initiated implementation of the DDN. The memorandum 
states [Ref. 10], 


"It remains DoD policy that all data communications 
users will be integrated into this common user network. 
Exceptions to this policy must continwe to trecerve ete 
SERENE of the Deputy Under Secretary of Defense for 


b. Under Secretary of Defense for R&E Memorandum of 
Oe Marcehi i sa.3 


This document reinforces the DDN mandate stating 
{Ref. 12], 


— 


"Existing systems, systems being SP alee and upgraded, 
and new systems _or data networks will become DDN 
subscribers. All such systems must be registered in the 
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DDN User Requirements Data Base (URDB); Once registered 
in the URDB, requests by a SS a es “tetas for an - 
exception to this policy shall be made to DUSD C3l. 


e. OPNAV Instruction 2070.4 of 7 March 1984 


This document provides guidelines for Department 


of the Navy implementation [Ref. 13]. 


", . . the DDN will be used by all DOD ADP systems and 
data networks requiring interconnection b 
telecommunications. Any requests for waivers from this 
policy must clearly show why DDN cannot meet the 
requirement. Waivers for periods of more than 2 years 
can only be approved by Deputy Under pecrelary O 
Defense, DUSD Gees yp aivers for periods of less than 2 
meee: can only be granted by DCA if CNO and DCA agree 
Mae it 1s justified. 

This instruction applies to all Navy ADP systems and 
data networks requiring data communications Services. 
Long-haul and area communications, interconnectivity, 
and the capability for interoperability will be provided 
by the DDN. This includes existing ADP systems, ADP 
systems being expanded and upgraded and new ADP systems. 
All commands will ensure future ADP acquisitions which 
feqduire data communications include provisions for using 
the DDN as their primary data communications medium. 


Promulgation of the three documents cited above, 
ieparticiular the last one, provide the rationale for SPLICE 


long haul data communications through the DDN. 
5. Growing Pains in the DDN 


It can fairly be argued that the scope of Service 
that DDN is ultimately to offer eclipses most other packet 
Switched network implementations with the possible exception 
of the commercially available Tymnet and GTE Telenet. 
However, the DDN goes much further than these two commercial 
Systems. Tymnet and GTE Telenet offer a method of 
point-to-point transmission. However, unlike DDN, they do 
not offer implementation of higher level protocols which 


will ensure reliable transmission and process-to-process 
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communication. In this respect, the DDN is a large capital 
venture that rides the leading edge of technology in a new 
applications area. 

As of July 1985, there were approximately 90 
Switches in the DDN. Between July 1985 and April of 1986, 
another 182 switches are to be installed. Clearly, the DDN 
is in the midst of massive growth. With it come growing 
pains. The basic architecture and technology for 
implementation of the DDN has been proven through the 
ARPANET. However, the ARPANET implementation was relatively 
Slow and gradual over a period of fifteen years. It is 
dwarfed in comparison with the scope and rapidity of DDN 
implementation. Therefore, it can be expected that actual 
physical installation and implementation problems will 
trouble DCA over the next couple of years. The three 
directives cited in the previous section illustrate the 
urgency with which the Department of Defense intends to 
convert existing and new data communications applications to 
the DDN. This will entail no small effort, and already 
implementation scheduling problems have emerged. 5PLIGEHweas 


no exception to this proptem- 


D. RECENT DEVELOPMENTS AND DDN IMPLEMENTATION COMPLICATIONS 


As alluded to previously, implementation of SPLICE long 
haul data communications through the DDN is not a simple 
matter. Full implementation into the DDN requires the 
implemention of different hierarchical protocols which map 
out a standardized methodology for data communications. 
Detailed discussions of these protocols are presented in 
Appendix B. It should be noted that few hardware vendors 
actually have the DDN protocol software available for Emeam 
Suite of hardware. The majority of the DDN protocol 


implementations currently available stem from ARPANET which 
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uses the same protocols. The number of hardware specific 
DDN protocol implementations are growing, and DCA is 
awarding contracts to various vendors and software houses to 
develop these protocols for certain major brands of 
hardware. However, Tandem Corporation is not one of the 
vendors that could offer these DDN protocols off the shelf 
to run on their Tandem NonStop TXP system hardware. 
Consequently, the SPLICE contract had to be written to 
include development and implementation of these protocols 
Meee: pp. 58, 186], [Ref. 14: p. 6]. Other 


implementation problems are addressed below. 
1. TSR (Telecommunications Service Request) Backlog 


TSRs are the vehicle by which telecommunications 
lines are ordered by the armed services and agencies of the 
Department of Defense. TSRs are centrally coordinated and 
handled for the Department of Defense by the Defense 
Communications Agency. The rapid increase in distributed 
computer systems applications, local area network 
implementations and connectivity requirements into the DDN 
have resulted in a logjam of TSRs forwarded to DCA. The 
sheer increase in volume accounts for some of the delay in 
getting connections for ADP applications. Moreover, 
divestiture of AT&T has created another problem as cited by 
the 15 May 1985 DDN Newsletter [Ref. 15: pp. 1, 6]. 


Bemeecuyt acquisition (both access and trunk circuits) 
continues to be a problem. The regional BOCs (Bell. 
Peete Companies) are reluctant to do business with 
ATTIS (American Telephone & Telegraph Information 
Systems); consequently we have over 230 circuits 
backlogged with no clear idea of when _ this nee jam will 
be cleared. The Commercial Policy folks at DCA as well 
as the DCA Regulatory Counsel are working on this issue. 


In FY 1983, a_ total of 521 DDN TSRs were processed, and 
et 1984.09290 (DDN TSRslwere issued. So far in FY 
ioe a total of 800 DDN TSRs ete, were processed, 
with an estimation of 3,000 DDN TSRs to be processed 
during the FY 1985 year. Presently, this section 
processes approximately 40 DDN TSRs to the field each 


ae 


week, including user requirements, backbone trunks and 
aval ais service lines to the TACs (Terminal Access 
Controllere |). 


NAVSUP (Naval Supply Systems Command) Headquarters 
has a DDN waiver for SPLICE that expired on 31 Mareh Ice 
[Ref. 16], [Ref. 17]. Due to a myriad of scheduling 
problems, not the least of which is the difficulty in 
processing TSRs and obtaining connections into the DDN, an 
extension of this waiver has been requested through 
COMNAVTELCOM (Commander, Naval Telecommunications Command) 
[Ref. 18], [Ref. 19]. Because the waiver has expired, 
NAVSUP currently has no legal vehicle by which to obtain 
telecommunications connections for SPLICE installations. A 
dozen SPLICE to DDN connection TSRs were backlogged in July 
1985. The average age of these TSRs is about 9 to 12 
months; some of them are as old as 15 months. In early July 
1985, the first two SPLICE TSRs were finally completed. 
These were for a 56,000 bit/second connection from the FMSO 
(Navy Fleet Material Support Office) Mechanicsburg, 
Pennsylvania SPLICE site number l into the DDN, and another 
56,000 bit/second connection from NARDAC (Navy Regional Data 
Automation Center) Jacksonville, Florida SPLICE site into 
the DDN. Unfortunately, DCA was not able to physically 
deliver a 56,000 bit/second line into FMSO, so a 9,600 
bit/second line was substituted until a 56,000 bit/second 
trunk could be negotiated and connected. Thus at the time 
of writing this document, there are only two SPLICE DDN 
connections physically in existence. 

A self contradicting situation has ensued. Federal 
Data Corporation as the SPLICE prime contractor as 
responsible for the development and implementation of the 
DDN protocols cited earlier. To implement and test these 
protocols, the contractors ' hardware test beds must be 


connected into the DDN. Two TSRs requesting connection of 
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Federal Data Corporation (TSR DULOMAY840576) and Tandem 
Corporation hardware test beds (TSR DUO7AUG841132) have been 
backlogged since 2 May 1984. As a result, the prime 
contractor does not have the physical connections necessary 
to implement and test the DDN protocols currently under 
software development. Until these protocols are tested and 
implemented, SPLICE is unable to break the yoke of having to 
Operate under a DDN waiver. At the time of writing, the 
request for DDN waiver extension [Ref. 18] was still 
unresolved. Yet, even if the SPLICE DDN protocols were up 
and running, SPLICE would be unable to function as a wide 
area network because of the physical unavailability of DDN 
connections due to backlogged TSRs. Neither can SPLICE 
operate outside the DDN as a wide area network using 
dedicated lines leased from commercial carriers, because the 


DDN waiver has expired. 


2. DDN Asynchronous Terminal Data Communications 
support 


As shall be noted later in the discussion of 
protocols, the DDN is configured to support only 
asynchronous terminal data communications. ASynchronous 
communication has tremendous advantages due to simplicity of 
operation and implementation. In asynchronous mode, 
characters are transmitted one at a time, and the rate that 
the data is transmitted 1S variable. This means of 
communication is Simple and cheap, but requires an overhead 
of 2 to 3 bits per character [Ref. 8: p. 26]. The overhead 
fmeauired 1S for start and stop bits. Normally a constant 
bit stream of ls is sent over the line. When the receiver 
fmees 42 transition from 1 to 0, this indicates the beginning 
MEmenacarcter  tinis © bitels called a start bit. After 
Buemciaracter 15 Eransmitted, the sender resumes sending 1! 


mearomcdoawn the line until the next character is to be 


at 


transmitted. This translates to a relaeivel, higaerateee. 
overhead, a minimum of 25% to 37.54, for 8 bit byte 
character transmission. Unfortunately for SPLICE, very few 
of the presently installed CRT terminals at the major stock 


points are asynchronous. 


3. Burroughs Bisynchronous Terminal Data Communications 


SUDPOLE 


The major stock points have CRT terminals installed 
that are connected to the Burroughs mainframe. These CRT 
terminals run on Burroughs bisynchronous transmission 
(poll/select) protocol. As one might infer from the name, 
bisynchronous transmission requires accurate clocking So 
that the transmitter and receiver are in step, or 
synchronized. In this method of transmission, blocks of 
characters are tranSmitted without the start and stop bit 
codes encountered in asynchronous transmission. The exact 
departure and arrival time of characters is known. The 
beginning and end of each block of characters transmitted is 
delimited by synchronization characters. These 
Synchronization characters are entirely different in type 
from normal data that is to be transmitted [Ref. 3: pluie 

There are two big advantages to this type of 
terminal data communications. First of all, it is poss aoe 
to communicate in a Screen mode. That is, the entire screen 
of a CRT display is used, enabling displays of menus and 
format templates which are essential for proper editing of 
data entered by clerical personnel. The templates may show 
the proper format for data entry, and guider rne clersc.= 
personnel from data entry block to data entry block. ~Aeeuee 
screen of data on a normal 24 line, 80 character per line 
terminal is 1920 bytes of information. The second big 
advantage to synchronous communication is the high rate of 


data transfer that can be attained. Since it is a clocked 
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system, and blocks of data can be transmitted, the entire 
1920 bytes of screen data can be transmitted in one block. 

One of the big problems that the DDN currently poses 
Eee oELILCE is the inability to support the Burroughs 
bisynchronous terminal communications. What this means is 
that a Burroughs terminal connected to a SPLICE node at say, 
NSC Oakland, CA, will be unable to communicate via the DDN 
with the Burroughs mainframe at NSC Norfolk, VA. Moreover, 
communications between an asynchronous terminal connected 
into the DDN through a TAC (Terminal Access Controller) 
would be unable to converse with a Burroughs host at a 
SPLICE node using the Burroughs bisynchronous data 
Sammunications protocol. 

This obstacle can be overcome, but it will require 
development of telecommunications software to wrap this sort 
of communication up and carry it between Oakland and 
Netfolk. If a smart terminal is connected to a SPLICE host 
via a DDN TAC, this same sort of software would be required 
to wrap and unwrap the Burroughs bisynchronous terminal data 
communications PeCcCeg el Gadicmmol snowever, Ceasible to 
invoke this bisynchronous protocol between a SPLICE host and 
a dumb terminal. At this time, no such software is 
developed, and there are no plans to develop it. The 
Burroughs hardware is scheduled to be replaced as a result 
Seemtehne SPAR (Stock Point ADP Resolicitation) project. 
Investment of software development into a system that is 
likely to be replaced in 3 to 5 years is not being 
considered. Furthermore, the bisynchronous method of 
terminal data communications is rapidly becoming obsolete 
and is being replaced by a synchronous data link protocol, 


which is discussed below. 


, 


4. IBM SNA SDLC Synchronous Terminal Data 
Communications Support 


One of the items that is never mentioned in the 
SPLICE Functional Description [Ref. 1] or the SPLICE Systems 
Specification [Ref. 3] is the requirement for SPLICE to ep 
as a front end processor for the IBM 3081 series mainframes 
that are being installed at the ECPs "(invemtory Contram 
Points). These IBM 3081 machines communicate with IBM 
terminals in a local area network using IBM's SNA (Systems 
Network Architecture) SDLC (Synchronous Data Link Control) 
protocol. Closely coupled with this requirement is the need 
for the ICPs to communicate with the Trident Refit 
Facilities and to interface with the CAIMS (Conventional 
Ammunition Integrated Management System). These 
applications are apparently also going to utilize IBM 308X 
series hardware. So the scope of communications problems no 
longer is limited to applications currently being Supported 
by the Burroughs and Perkin-Elmer mainframes at Stock 
Points. Now we have a communications problem between 
different communities outside the purview of SPLICE. Again, 
the problems that synchronous terminal data communications 
pose for SPLICE are similar to those cited previously for 
the Burroughs bisynchronous terminal data communications 
problem. 

The IBM SNA SDLC is a bit oriented synchronous mode 
of communications that is rendering the character block 
bisynchronous mode obsolete. This bit oriented scheme 
treats the block of data to be transmitted as a continuous 
bit stream rather than a character stream ne 
synchronization characters for delimiting the beginning and 
end of block transmission cannot be lisecdtcamce a. 
transmitted data is assumed to be am arbitrary bie patterom 


and such patterns may be legal data to be transmitted. SDLC 
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uses the bit pattern 01111110 as a preamble and postamble 
delimiting bit pattern to accomplish the same task that the 
synchronization characters provided in bisynchronous 
communications. The problem of 6 consecutive 1 bits 
appearing in a data stream as data and being misinterpreted 
by the receiver as a preamble or postamble bit pattern must 
be solved [Ref. 8: p. 27]. It is solved by a procedure 
known as bit stuffing. The transmitter will always insert 
an extra O bit after any occurance of five 1s in the data 
Meine transmitted. In the event that the pattern 01111110 
(the left end being the start of the pattern) is actually 
sent as data, the transmitter will insert a O after the 
fifth 1 so that the data sent is 011111010. When the 
receiver gets the data it always examines any set of five 
consecutive 1 bits. When it detects five l Diese adet checks 
myeemext bit to see if it is a 0. If it is a 0 bit, the 
receiver deletes it. In this manner, the only reason that 6 
consecutive 1 bits will be transmitted is if it is either 


the preamble or postamble bit pattern delimiter. 
5. Interface With European MILNET Terminals 


The European section of the MILNET, still better 
known as the old MINET, also poses a possible communications 
problem for SPLICE. There is a gateway between the European 
MILNET (MINET) and the CONUS (Continental United States) 
Pettion of the MILNET. In order to process any traffic 
through this gateway, IP (Internet Protocol) and TCP 
(Transport Control Protocol) must be implemented. It is not 
possible to implement communication with users or hosts in 
this subsection of the DDN by using the CCITT (Consultative 
Committee for International Telephone and Telegraph) X.25 
standard and a commercial vendor higher level protocol 
Meet- 6: p. 41]. This negates the ability for SPLICE to 


implement an off the shelf set of network protocols 


oy 


available from Tandem Corporation to communicate with nodes 
in the European MILNET. 


SZ 


PiieeelueAcCi On THESEROPOSED TP-4 STANDARD 

One of the problems associated with the onset of 
Gietributed processing is the standardization of protocols. 
For the commercial environment, layers 1 through 3 
(physical, data link, and network) have largely been 
standardized through the CCITT X.25 specification. As 
mentioned in Appendix A, X./75 offers internetwork 
connectivity of X.25 networks. In the ARPANET environment, 
Beame@ardization for layers 1 and 2 (physical and data link) 
are based upon the ARPANET HDLC (High Level Data Link 
Generol) and the 1822 specification [Ref. 20]. In the 
ARPANET and DDN, the IP and TCP functions cannot be 
accurately mapped out as layer 3 (network) or layer 4 
(transport). In fact, between these two protocols many of 
the functions defined for layers 3 through 5 (session) are 
covered, and the correspondence between the ISO OSI model 
and TCP/IP breaks down. As of yet, there is still no 
commercially implemented standard for layer 4 (transport). 
However, the DoD and the NBS (National Bureau of Standards) 
have been working toward development of protocol 
standardization. The NBS ICST (Institute for Computer 
Sciences and Technology) in cooperation with the DoD, the 
ISO (International Standards Organization), and many 
industrial firms, have developed new international 
Standards. Two new protocols that are standardized are a 
new Internetwork Protocol and the TP-4 (Transport Protocol) 
Mere 21). The U. S. standards organizations are supporting 
TP-4 in international operations, and the Department of 
Commerce iS proposing that TP-4 become a FIPS (Federal 


Information Processing Standard) for the Federal Government. 
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Although TP-4 is based upon TCP, there are significant 
dissimilarities that would cause conversitom to wer 
complicated matter if DoD were to mandate TP-4 use in 
existing TCP applications. TCP was developed and first 
promulgated in 1978 and thus has a long and proven 
operational history. TP-4 has yet to be implemented. It is 
expected that a commercial TP-4 product will be available in 
the near future. TCP/IP were specifically developed to 
support DoD data communication demands in a hostile wartime 
environment. To this end, TCP/IP support the following 
requirements. 

* Survivability: Some networks must function, even if at 
reduced Pe ae Onan. after many nodes and links have 
been destroyed. 

* Security: Traffic patterns and data must be 
selectively protected through encryption, access 
control, auditing ands vovtane- 

¢ Precedence: Systems should adjust the quality of 
service dependent upon the basis of priority; 
Capability for preemption by higher priority must be 
available. 

* Robustness: The system must not fail or suffer much 
loss of capability due to unpredicted situations, 
unexpected loads, or misuSe. 

¢ Availability: Elements of the system needed for 
operational readiness or fighting must be continuously 
available. 

¢ Interoperability: Different elements of the DoD must 
be able to communicate with one another, often in 
unpredictable ways, between parties that had not 
planned to interoperate. 

The operational needs cited above translate to five 
technical and managerial needs for the DoD. 

* Functional and operational speertieaeuans- 

¢ Maximum interoperability. 

* Minimum procurement, development and support costs. 

« Ease of transition to new protocols, 

* Responsiveness to changing DoD requirements. 

TCP and TP-4 are functionally equivalent, providing 
essentially similar service, though their architectures are 


dissimilar. Although there are differences between the two 
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Eaorocols, the NRC is confident that TP-4 will meet military 
requirements. The DoD could incur significant long run 
Savings through implementation of an international standard 
with a wide commercial application. On the other hand, a 
Significant investment in TCP has already been made, and 
Meatisttion of current TCP applications to a new TP-4 
standard could prove prohibitively costly. However, the DoD 
has a need for functional interoperability with a wide 
number of agencies and activities external to it. These 
agencies and activities are committed to the ISO standards. 
They include NATO (North Atlantic Treaty Organization), 
different intelligence and security agencies, and other 
segments of the Federal Government. The National Research 
Council, whose report is discussed herein [Ref. 21: p. 8], 
states, "The same objectives that have prompted the use of 
Standardized protocols at higher level headquarters will 
lead to their use by tactical groups in the field.” 

"The Internet Protocol part of the standards is not 
believed to be a problem. The ISO IP is not as far along as 
TP-4, but it is much less complex." [Ref. 21: p. 9]. The 
progress being made in development of the ISO IP and TP-4 is 
memyerapid. This is due in large part to a strong 
commercial demand for integration of data processing and 
networking, and the efforts of vendors to meet this new 
demand. In spite of the fact that the DoD was instrumental 
in development of TCP, which is a model upon which the ISO 
Meee 1S built, there is little chance that DoD will have 
much influence in altering TP-4 to conform with TCP. This 
is mainly because the DoD represents a small fraction of the 
total market for TP-4 implementation, and because the United 
States Supports the ISO standard. Thus DoD was faced with 
making a decision regarding the implementation of TP-4 and 
mae Luture of TCP. 
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The NRC offered three options to DoD, and recommended 
implementation of option PiRet . 2ie sppeno sen cue 


"Option 1: The first option isptor thes volmLo 
see modify 1tS Current trancporteepel cae 
Soa o specify TP-4 as a costandard along with 


Option 2: Under option 2 the Department of Defense 
would immediately announce its intention to adopt TP-4 
as a transport protocol costandard with TCP after a 
satisfactory demonstration of its survivability for use 
in military networks. A final commitment would be 
deferred until the_ demonstration has been evaluated and 
TP-4 is commercially available. oe 

Option 3: Under the third option the DoD would continue 
oe TCP as the accepted transport standard and@deten 
any de 


cision on the uSe of TP-4 indefinitely. 

The Assistant Secretary of Defense for Command, Control, 
Communications and Intelligence rejected the NRC 
recommendation of Option 1, which would immediately mandate 
TP-4 as a costandard with TCP [Ref. 22], and ultimately move 
toward exclusive use of TP-4. Instead, DCA was directed to 
Study and implement option 2. The meaning to all users of 
the DDN is that there is no current definitive strategy that 
they can count on five to ten years hence. At the moment 
the DoD TCP/IP is the standard but it is clear that thieg 
change over the next decade. In any event, it is clear that 
DDN will support the DoD TCP/IP for at least the next 
decade. This affects SPLICE internetworking and higher 
level protocol implementation strategy. If software 
development of internetwork processes and remote online 
processes place a heavy dependency on the inner workings of 
TCP/IP, significant coupling between application modules and 
TCP/IP modules will result. This will make conversion to a 
different standard some 5 to 10 years hence costly and 
painful and will hamper any resolicitation and replacement 
efforts involving SPLICE. 
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IV. SHORT-TERM REQUIREMENTS FOR TRANSPARENT INTERNETWORK 
CONNECTIVITY THROUGH SPLICE 


As stated at the beginning, the long-term payoff for 
peor lies in its ability to support distributed computing. 
The long-term goal of SPLICE should be to effect transparent 
processing for the user. SPLICE should satisfy a user 
requirement without concern on his part with processes or 
machines to be used. The uSer should be dealing with the 
entire logistics system as an entity, and he should be able 
to interface directly with all facets of it in a global 
fashion. Software has not been developed yet to implement 
such internetwork process transparency. As of now more 
traditional specific machine and site dependent processes 
must continue. In the interim phase, there will be a need 
Memaecess and conduct transactions against specific SPLICE 
fmeees- this chapter will address the aspects of invoking 
such connections and transactional processes. Chapter V 
introduces the requirements for effecting true transparent 
interprocess connectivity, a long-term goal for SPLICE and a 
concept that will eliminate the need for many of the 


procedures to be discussed in this chapter. 


Pee USER TERMINAL TO REMOTE PROCESS CONNECTIVITY 


This method of interprocess communication will most 
visibly change the way customers, expediters, and clerical 


personnel at the stock points and ICPs do business. 


i Stock eheck of Material at Stock Points and ICPs 


Dee ene eee 


It has been the long-standing goal of supply 


personnel in direct support of repair and maintenance to be 
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able to query the records of local and remote stock points 
and ICPs in search of high priority repair parts.) [aise 
commonly referred to as performing a “stock check." It is 
the bread and butter of all supply personnel engaged in 
expediting repair parts. Even before the implementation of 
SPLICE, a select few terminals and internetworking systems 
have been implemented to provide limited query capability of 
the ICPs and stock points at major commands, most notably 
the Type Commands. Primarily however, this capability 
exists among a select few stock points and ICPs. For 
instance, SPCC has the ability to query stock levels at DLA 
(Defense Logistics Agency) Depots. Supply clerks engaged in 
direct support of an organizational maintenance effort 
currently do not have the ability to perform remote stock 
checks .“ “SPLICE wid wenanecewrnate 


2. Requisition Status Queries at Stock Points and ICPs 


mr 


The second major query transaction of interest to 
customers in direct support of maintenance is "Requisition 
Status.’ Material has been ordered from the system, and the 
requisition 1S in process. This type of query is typically 
generated when a repair part is identified as being urgently 
needed for repair of equipment. The repair effort is ina 
“workstoppage" situation that is frustrated for lack of @ene 
part, and can proceed no further until it arrives. Queries 
of requisition status attempt to identify the precise state 
of nature that the requisition is in, whtehedcti1 7) =e 
currently handling it, and what is the expected delivery 


GatkeL or teen imate mace 


3. Administration of User TVermana) .eecounts ona 


Passwords within SPLICE 


For the most part, the applications requested will 


be stock checks and requisition status queries. These are 


Sis) 


likely to be the only capabilities that the most rudimentary 
account holder, hereafter referred to as an "anonymous 
public domain account," would possess. Applications 
involving execution of transactions would require a higher 
level of account capability. These are application 
capabilities that clerical personnel at the ICPs, stock 
points, and major commands would require. The temptation 
may be great to implement a login procedure from a user host 
to a server host that will give blanket account authority to 
a certain class of terminals. This must be avoided and not 
implemented. A specific example follows. 

Suppose a bank of 20 terminals at NSC Oakland are 
physically located in a specific office such as 
"Requirements Department." One might be tempted to conclude 
that no one without a legitimate need to conduct 
transactional applications against a remote stock point 
Server host would ever be working on these terminals. It 
may be expedient from a software engineering standpoint to 
program a general login procedure from any of those 20 user 
terminals with a remote stock point server host. This login 
procedure would automatically link to an account at the 
Server host with higher level application capabilities. 

What is the premise for this action? Presumably, when a 
terminal in “Requirements Department’ is activated, a local 
login procedure is executed, and a bonafide "Requirements 
Department’ clerk has gained access to the local SPLICE 
system with capabilities commensurate with his account. So 
why go through a complex login procedure with a remote 
server host once this is effected? Simply this. The person 
who originally logged into the local SPLICE host may have 
walked away from the terminal hours ago leaving the terminal 
unattended. Even if there is a timeout mechanism for 
automatically logging out an inactive terminal there will 


always be a window available for an illegal user to 
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penetrate the local system. If he succeeds in this, he may 
attempt to penetrate a remote stock point or an ICP. He 
will again succeed if the terminal he is illegally using 
will automatically login to an account with high level 
application capabilities at remote server hosts. Hence the 
need for the requirement that all accounts at local SPLICE 
systems as well as remote SPLICE systems have login 
procedures that are driven by individual accounts and 
passwords. The integrity of remote SPLICE node data will 
inevitably be compromised if a tight system wide login 
protocol is not enforced for all but anonymous public domain 
a2cCeounes: 

Each terminal user will have his own account and 
password. It is recommended that a user's password be 
recognized and universally honored by all SPLICE nodes. 

This will facilitate easy access to the myriad of different 
high level accounts a user may possess at different SPLICE 
nodes. The user should be able to change his password 
whenever he feels it is necessary and still have it 
universally honored by all SPLICE sites. Such a password 
management process would necessarily require centralized 
accounts and a password management software module. 

One possibility for account implementation would be 
for all high level accounts with remote capability to be 
centrally administered, say by FMSO. The accounts and 
passwords could be revalidated and repromulgated dynamically 
to all SPLICE nodes concerned. This process of updating the 
accounts and passwords on a real time basis may be somewhat 
involved, but it could be accomplished using end-to-end 
encryption offered by the DDN to update account and password 
tables at different SPLICE sites. If am account linkedweaemee 
certain person is found to be abtised, intormation coulcmee 
transmitted from the central account administrator to 


disable that account almost immediately at all SPLICE nodes. 
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A drawback to such a scheme is that one might find a way to 
penetrate the accounting systems software, and effectively 
disable everyone's capabilities. Sufficient care must be 
exercised in design of such a system and its modules to . 
minimize this threat. 

A second method for implementing high level account 
control would be for each SPLICE site to administer and 
authorize high level accounts used at its site. Under such 
a system, the Commanding Officer would have more control as 
to which people external to his command have high level 
transaction application capabilities. The drawback of this 
Seetem 1S that it would not have uniform criteria for 
granting accounts, and some systems would have easier access 
than others. In extreme cases, the management of high level 
accounts at a certain command might be so restrictive as to 
impede the normal flow of distributed processing. 

The bottom line is that with the exception of 
anonymous public domain accounts, all user terminal accounts 
must be strictly linked to individuals. ©“ Implementation on a 
system wide basis is a problem that must be addressed and 
solved if the benefits of distributed processing are to 
accrue while concurrently maintaining adequate security. 

One may argue that there is no instance whereby 
Supply personnel at a remote terminal would ever have the 
need to execute high level application transactions against 
a geographically distant stock point. Therein lies the 
double edged sword of distributed processing. It allows 
greater system wide visibility and efficiency, while 
compromising the local control over files that heretofore 
were the exclusive domain of a stock point or ICP. It is 
inevitable that the Fleet Commanders will want higher level 
application capabilities, such as releasing critical 
material from war reserve stock. In a distributed 


environment, they will demand this capability and eventually 
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they will get it. Such capabilities will be demanded on 
down the line until at some level external to the supply 
System they are cut off. Perhaps it will be at the Type 
Commander level. <A Scenario can be envisioned whereby 
COMNAVLOGPAC will have certain universal transactional 
capabilities that would exceed the scope of those granted to 
the Force Supply Officer at COMNAVAIRPAC. 


4. Requirements for Local SPLICE User Terminal 


Ce Eneeenenenenstillllitaueineamemmmeessntnmen 


In this situation, a terminal is directly hooked 
into a local SPLICE node. This may be a coaxial connection 


using Burroughs bisynchronous communications or IBM SNA 


SDLC. It may also be an asynchronous terminal hooked to a 
SPLICE node via the telephone PSN (Public Switched Network) 
and a modem connection. It 1S assumed that local login 


procedures to the local SPLICE node are well established, 
therefore they will not be addressed further. The problem 
begins when the local user terminal requires connectivity 
with a remote server host. Several things must happen. 


¢ The user terminal indicates to the local SPLICE host 
that a connection is desired with a remote SPLICE host. 


* The local SPLICE host, henceforth called the “user 


host,'. must establish a logical connection with the 
REDIEG SPLICE host, henceforth called the "Server 
os te 


‘ft 


* Once the connection is established, a “login procedure’ 
at the server host must be executed for the user 
terminal. 


t 


* The connection will either be honored or yea by 
the server host dependent upon server host login 
criteria. 

¢ If login is successful, the user terminal is now in a 
position to execute 2PP Cat commensurate with the 
USeGYr S A2c€cOUNEQGapan eine. 
Using the centralized account and password 
management criteria proposed earlier, the terminal user 
would have to enter his account data and password for 


transmission to the server host. However, the criteria for 


42 


accomplishing this connection should be limited to a request 
formeonnection to a specific SPLICE host and the entry of 
account data and a password. Account data should be simple. 
The user's name is recommended. Entry of the password 
Should not print out or display at the terminal. This 
brings up the question as to how the user must specify the 
server SPLICE host to be accessed. There will be from 35 to 
62 SPLICE nodes eventually. A "User Terminal To Server Host 
Transparent Connectivity Module,” hereafter referred to 
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simply as the "Connectivity Module," should be accessed. 
The Connectivity Module would offer selection menus, one of 
which would display a table of all of the different SPLICE 
nodes. The user should be able to browse the SPLICE table 
and select the server host that he wishes to connect with. 
The Connectivity Module would then effect the logical 
connection between the user terminal and the server host. 
After the logical connection is successfully effected, the 
Server host, through the user host Connectivity Module, 
would query the user terminal for account data and a 
password. The user would enter the account data and 
password. This would be transmitted to the server host. At 
Bis point, the user terminal should be successfully logged 
into the server host and in a position to execute 
applications commensurate with his account at the server 
nies t . 

The user should have the option of bypassing the 
selection menus offered by the Connectivity Module if he 
knows the correct symbols to enter for the server host he is 
interested in. Since almost all personnel in the supply and 
igermstics community are intricately familiar with MILSTRIP 
RICs (Routing Identifier Codes), these could be used quite 
effectively since there is a correspondence between RICS and 
SPLICE nodes. The RIC is a 3 character alphanumeric symbol 


and most supply personnel have at least a dozen or so of the 
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most important ones memorized. For instanee, if a user 
terminal at NSC Oakland, wants to connect with the server 
host at NSC Norfolk, he should be able to enter a command 
like: 
CONNECT NNZ 
or 
CONNECT NSC NORFOLK 
Entering a command such as CONNECT NNZ would obviate the 
need for experienced personnel to invoke the selection menu 
procedure. Entering a command such as CONNECT NSC NORFOLK 
would serve those who remember the common noun name of the 
activity they wish to connect with, but cannot remember the 
RIC offhand. Eventually, SPLICE will inte#act with stage 
points and ICPs outside of the Department of the Navy. The 
Connectivity Module should provide a table of RICS with DDN 
connections in addition to the abbreviated table of SPETGe 
nodes. Conceivably every RIC will eventually have 
capability for connectivity through DDN even if it 1S -oiieee 
microcomputer hooked into a DDN TAC (Terminal Access 
Controller). <A menu selection feature with UICs (Unit 
Identitiederon Codes) is another possibility for identifying 
remote hosts, but would probably not have as much utility as 
a RIC menu until communication with hosts outside the supply 
community becomes prevalent. 

Finally, the user terminal to Server host 
connectivity module should have a menu driven selection for 
connection with server hosts outside the SPLICE community. 
Presumably, this would include hosts that are connected 
through the DDN but not part of SPLICE.) ine Connective: 
Module should make the protocol of connectivity as painless 
and simple as possible for the unsophisticated user. All of 
the current hosts in the DDN could bé loaded into a file 
that could be called by the Connectivity Module. The 


contents of this file would have to be loaded from data 
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provided by the NIC (Network Information Center) RFC 
(Request for Comments) titled "Assigned Numbers" which is 
periodically updated and promulgated for ARPANET host 
adaresses [Ref. 23] and similar data maintained by DCA for 
MILNET host addresses. The user should then be able to 
browse the table containing all of the "Assigned Numbers" 
and pick the server host he deSires connection with. This 
would again be accomplished via selection menu procedures 
implemented by the Connectivity Module. This table would 
necessarily be much longer than the SPLICE table and 
therefore should not be the default table for finding a 
remote host. 

One method for implementing all of these table menus 
would be to set up a master menu that would query the user 
terminal to pick from: 

¢e SPLICE Remote Host Table 

* RIC (Routing Identifier Code) Remote Host Table 

* UIC (Unit Identification Code) Remote Host Table 

¢ Master DDN and ARPANET Remote Host Table 
Of course, all of these tables should be loaded into one 
database or flat file that is indexed to produce the 4 
selections outlined above. Other selection menu tables can 
be generated as required from this master address file. In 
fact, each individual user should be able to set up his own 
tailored table of hosts that he frequently communicates 
with, and have this tailored table be the default menu 


Selection. 


5. Requirements for Smart Asynchronous Terminal 
Commection to a SPLICE Hose 


The ability to effect transparent connectivity in 
Sif@cse situation is more difficult than that of a terminal 
directly connected to a SPLICE node. In this situation, we 


assume that the terminal is connected into the DDN via a TAC 
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(Terminal Access Controller) or MINITAC, which is a smaller 
version of the TAC. Many of the selection menu processes 
which can be readily implemented on Burroughs bisynchronous 
terminals or IBM SNA SDLC terminals are not as easily 
handled in this environment. This 1S because most of the 
remotely connected terminals will be asynchronous. If they 
are dumb asynchronous terminals, the problem is even more 
extensive. Let us assume for the moment that we are working 
with smart asynchronous terminals, in the form of PCs 
(Personal Computers). — 

If we deal with a smart asynchronous terminal, then 
it should be possible to program a module within the 
Connectivity Module to Support screen mode communications 
with the smart asynchronous terminal. Such a module would 
be downloaded from the SPLICE node to the smart asynchronous 
terminal as soon as connectivity is achieved. Full screen 
communication with a smart asynchronous terminal is 
complicated by the fact that normal communication appears in 
the scroll mode. This means that the current line appears 
at the bottom or 24th row on a standard screen, and pushes 
all data on the screen up one row. The top row of course 
disappears off the display when a new line appears at the 
bottom. Connection of these terminals directly into a DDN 
TAC or MINITAC is asynchronous, and this carries a2 high 
overhead per character Eransmi ted y 25 (hom) oeecmecice 
Such communication will not be as fast as that found on the 
bisynchronous and synchronous terminals directly hooked into 
the SPLICE Tandem machines but this does not rule out the 
utility of such connections. At eI200 9 b2e], seeonaeer 
greater, it should be quite satisfactory, certainly a boon 
to any shipboard environment which in the past has never 
enjoyed access to such direct connections into stock points 
and ICPs. This application of course should be the bottom 


line for asynchronous connectivity with priority given to 
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the solution of the shipboard asynchronous connectivity 
problem. This is where the greatest benefit to material 
readiness and the Navy's fighting capabilities manifest 
themselves. 

The most likely target for such an application would 
be the IBM PC and its clones that use the Intel 8088 
microchip. The second priority target for Such an 
application would be PCs that are based on the Zilog Z-80 
Mmm@eintel 8080 microchip. Not all smart asynchronous PCs 
may realistically be supported, but certainly the IBM, Z-80 
and 8080 PCs can and should be. The fact of the matter is 
that there is a large population of Zenith 100 and Zenith 
120 PCs in the fleet, and these are Z-80 based machines. 
The current favorite for the fleet seems to be the newer 
Zenith 150, which is an IBM PC clone. The shore 
establishment is not that much different; again there is a 
mix of IBM PCs, IBM PC clones, Z-80 and 8080 machines. 
Since all Intel 8080 microchip programs will execute on the 
Zilog Z-80 microchip, we can basically reduce the problem to 
enat of supporting Evite cCmmerOCND aGgeniteceures and — 
compatibility with two PC operating systems. The IBM PCs 
and IBM PC clones use IBM's PC-DOS operating system, or 
Microsoft Corporation's MS-DOS operating system. The basic 
features of PC-DOS and MS-DOS are identical in function and 
will run interchangeably on either the IBM PC or the IBM PC 
clones. The Zilog Z-80 and Intel 8080 microprocessors run 
under Digital Research Corporation's CP/M operating system. 

A basic monochrome terminal that doesn't support 
reverse images or highlighting should be assumed. Thus, 
some fancy features that are supported on more complicated 
Screens will have to be sacrificed. This should not affect 
many applications. Right now there are very few if any 
bisynchronous or synchronous color terminals hooked directly 


into SPLICE Tandem machines, so color is really not an 
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issue. What reverse imaging and highlighting does exist may 
just have to be sacrificed in remote asynchronous 
communications. But this does not Wipe out the utility of 
Supporting full screen management with such hardware. 
Microchip programs that will conduct Screen management are 
definitely possible. Witness the many PC software packages 
that employ menu facilities for prompting users through 
different applications. This same methodology can be 
employed for the remote smart asynchronous terminal. 

The question 1S whether the entire screen management 
protocol and asynchronous communication protocol with the 
TAC can be handled in 64 kilobytes or less of memory. 
Programming of the screen management modules for the smart 
asynchronous terminals should assume a machine architecture 
with 64 kilobytes of RAM (Random Access Memory). If the 
limitation of 64 kilobytes of RAM (Random Access Memory) is 
too restrictive from a software engineering standpoint, 
perhaps the lower limit of smart terminal Support should be 
i286 kilobytes of RAM: 

An alternative implementation of full screen 
management, and one that may prove most expedient in the 
Short-term, would involve the use of off the shelf PC 
software. These would include communication packages, 
Simulator packages, and programs executed from floppy disk 
to emulate full screen modes found on the Burroughs 
bisynchronous and IBM SNA SDLC terminals. There are already 
a number of packages that provide asynchronous communication 
such as those marketed by IBM and Hayes. The problem is 
determining if they are compatible with direct hookup into 
Tandem hardware. We do know that these communications 
packages will allow connectivity into a DDN TAC. Other 
packages are marketed that will emulate the bisynchronous 
features of IBM 3270 terminals and IBM 3278 terminals. It 


may be just possible that one of these packages can be used 
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to emulate the Tandem terminals. If an off the shelf 
software package cannot be found that emulates the Tandem 
terminal, the next best thing would be to develop software 
for use on the PCs that would emulate the different menus 
and Screen management facilities offered by the Tandem and 
Burroughs hardware for the bisynchronous terminals that are 
directly connected into the Tandem hardware. After a 
communications package such as Hayes Smartcom software is 
executing, and a connection is effected, the PC could be 
Switched from terminal communications back to a stand alone 
PC. In this stand alone mode, a PC Menu Selection Module 
could be invoked that offers full Screen management that 
steps unsophisticated users through processes such as "stock 
etc. The 
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ehecks,' "requisition status query,’ 
unsophisticated user would enter the data he is prompted 
for, making full use of "program function keys,” the 
cursors, "page up” key, "page down” key, etc. All of these 
Special function keys would be Supported by the PC Menu 
Selection Module. Each menu should Support a specific genre 
of transactions and should offer online data entry 
validation support. This online data validation Support 
would typically do things like check whether a stock number 
entered has the correct number of digits, no alphabetic 
characters embedded in the wrong place, etc. The PC Menu 
Selection Module should have a bank of validation tables 
used to catch gross data entry errors for immediate online 
correction. Once the user has completed entering all the 
fataetor a2 particular class of transactions, he would 
indicate so to the PC Menu Selection Module, presumably by 
hitting one of the "program function keys." He may have 
only one stock check, or he may have entered 30. The PC 
Menu Selection Module will then transfer control to the PC 
Communications Module and send the transactional data 


entered in the stand alone mode as a file to the SPLICE 


49 


Tandem processor. The information received by the Tandem 
processor would be handled in a batch remote job entry 
fashion. The transactions would be processed and the 
results transmitted back to the user PC terminal. It is 
believed that handling transactions from asynchronous 
terminals in this manner iS superior to basic online 
asynchronous transaction capability.” Basievasynenronoeus 
transaction processing would not be user friendly, and would 
require the user to explicitly invoke all of the processes 
desired. This requires a high level of technical and 
systems expertise, a commodity rarely found in the fleet 
subject to constant turnover and influx of new personnel. 
Without the use of menus, templates, online help facilities, 
and user prompts, the benefits of SPLICE will be restricted 
to a small fleet audience. A PC Menu Selection Module would 
open the benefits of SPLICE to relatively untrained 
personnel, delivering critical real time information with 


minimum expenditure of skilled manpower resources. 


6. Rationale for Nonsupport of Dumb Asynchronous 
Terminals by SPLICE 


Although many "dumb" terminals abound throughout the 
Navy, further investment in the use of these terminals for 
SPLICE applications is not warranted. By a "dumb" terminal, 
we mean a terminal with no internal processing capabilities, 
and limited buffering capability. All keyboard actions must 
be transmitted to the host computer which interprets the 
data and controls the terminal. Since there has been such a 
proliferation of PCs throughout the Navy, it would be more 
expedient to concentrate on communications between SPLICE 
and PCs, which have their own storage and processing 
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capabilities. Supporting the "dumb"~terminal in an 
asynchronous environment is of very limited value due to its 


inherent limntedevonce 
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7. Requirements for SNAP I and II User Terminal 


me OS 


Connectivity with SPLICE Hosts 


The reasons for supplying SNAP I and II user 
terminal service into SPLICE are the same as with the smart 
asynchronous terminal. In fact the need is greater in this 
environment due to process-to-process interfaces between 
SNAP I and SNAP II processes and SPLICE. This 
process-to-process interface will be discussed later. The 
capability for supporting full screen management for SNAP I 
and II user terminals is greater than that found in the 
asynchronous stand alone PC environment. More efficient 
Simulation of full screen mode is feasible which will 
Support response times more in line with that expected from 
an online system. The major drawback to actual synchronous 
or bisynchronous terminal communications is the fact that 


connections into the DDN are asynchronous. 


8. Requirements for Burroughs Bisynchronous and IBM SNA 
SeLC Useretermi nal @ounectivity with SPLICE Hosts 


As mentioned earlier in Chapter II, there is a need 
for transparent connectivity with IBM SNA SDLC user 
terminals which are being implemented at the ICPs, the 
Trident Refit Facilities, and CAIMS. Although these 
applications were not specified in the original Functional 
Description [Ref. 1] and System Specification [Ref. 3], it 
is clear that these applications are going to have an impact 
on SPLICE in the immediate future that is second only to the 
Burroughs bisynchronous communication problem. Until these 
user terminal compatibility problems are solved, user 
terminal to remote server host applications will be stymied. 
This is probably the most immediate and pressing problem to 


SPLICE implementation as of the time of writing. 
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B. ELECTRONIC MAIL FACTEGITY [THROUGH eS EluicE 


One of the clear advantages of electronic mail 1s the 
Speed by which textual Eraffie is transmitrwed, amen ic 
efficiency by which it iS queued and processed by the 
receiver. In the logistics environment, the benefits would 
be great. An extraordinary amount of clerical time is 
wasted in the logistics environment trying to get a hold of 
a point of contact to get something accomplished or to 
transmit germane day to day operational information. 


Presently, this effort manifests itself in 3 basic ways. 


1. Unreliability of Telephone Communication in the Navy 


The most popular method of communication in the 
military is the telephone. But lack of reliable telephone 
service is probably the number one impediment to 
productivity in the Department of Defense. Even under 
conditions of perfect telephone service, the probability 
that a called party will be available for conversation 1s 
low. Time and space will not allow a digression into the 
frustrations of telephone communication while personnel are 
engaged in the day to day effort of running the Navy, in 
particular, the Navy logistics community. It is assumed 
that the reader finds these frustrations to be self-evident. 
This affects most negatively personnel at the grass roots 
level of clerical processes and middle management. GS-5 
through GS-11 personnel frustrated in the accomplishment of 
their jobs due to inability to communicate with peers, slip 
into an unacceptably low level of productivity. This 
inability to communicate via telephone usually manifests 
itself in substitute forms of communication. For poinrtsmen 
contact in close proximity, written or typed Memorandums are 
used. For personnel outside the local geographic area, 


Naval Letters and Naval Messages are often used. 
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The latter two forms of communication result ina 
high clerical overhead and cost. The letter is slow, and 
the message is often not received. While the message can 
generally be relied upon to transmit information within 24 
hours, it is no longer an informal means of communication. 
Both the Naval Message and the Naval Letter carry the weight 
of official command correspondence. The chain of command in 
the process of chopping Naval Messages and Naval Letters 
cuts out pertinent information, and often inserts unwanted 
information. The original informal communication intended 
is not transmitted, doing further damage to the informal 
communication infrastructure that would allow our Navy to 


operate more efficiently. 
2. Requirements for Electronic Mail 


Electronic Mail packages are quite common. It 1s 
the most common way through which much technical information 
1S passed between personnel in the research community 
through the ARPANET. It has and is working very effectively 
as a substitute for telephone conversation and written 
eeerespondence. It has the advantage of being very 
inexpensive, timely, reliable, and accurate. Multiple 
addresses as well as distribution lists can be utilized, 
resulting in the simultaneous and near instantaneous 
transmission of information. It has the distinct advantage 
over other written forms of communication in that the only 
clerical overhead is that incurred by the drafter. The SMTP 
famole Mail Transfer Protocol) [Ref. 24] adequately covers 
the technical details for an electronic mail specification. 

- An excellent and powerful electronic mail software package 
that should be expanded upon to implement the SPLICE 
Electronic Mail Module is a facility called "MM" 

[Ref. 25,26,27]. MM has been implemented under the DEC 
(Digital Equipment Corporation) TOPS-20 operating system 
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[Ref. 28] and is widely used in the ARPANET community. MM 
offers the advantage of being in full compliance with SMTP 
specifications. Although MM offers excellent and powerful 
electronic mail processing facilities, it is currently 
geared for operation in the asynchronous mode of 
communication found in the ARPANET and DDN. Therefore, it 
operates in the scroll mode discussed earlier, requiring the 
user to explicitly type in and enter commands. an 
Electronic Mail Module should be developed using MM as a 
baseline. It should be enhanced to implement user friendly 
functions that step the novice user through to a successful 
transmission of electronic mail on his first attempt. This 
would include the use of template and formatted full screen 
capabilities to Support multiple menus, online help 
facilities, use of program function keys, etc., as discussed 
earlier. The Electronic Mail Module should offer default 
use of a full screen user friendly word processing package. 
This word processing package should allow the novice to 
draft a clean and legible piece of correspondence lonsna 
first attempt without undue frustration. A package such as 
PEACHTEXT should be investigated for this function. 


C. PROCESS TO PROCESS CONNER GLE ai 


The physical implementation of SPLICE hardware at the 
Stock Points and ICPs will not simply result in interprocess 
communication within a closed Navy Stock Point amaeIicr 
environment. Since all SPLICE nodes will be connected 
through the DDN's MILNET, the potential exists for 
interprocess communication with any host in the MILNET 
System. This opens up doors that will allow 
interoperability of all logistic systems throughout the 
Department of Defense. In addition to this, it allows the 


interoperability of maintenance systems with logistic 


54 


systems. The possibility is real for true interoperability, 
coordination and communication between the Navy's 
maintenance processes and the logistic processes. To 
capitalize on these capabilities, farsighted decisions must 
be made that will ultimately support interoperability of 
systems that never before had a need for, or even 


contemplated communication with each other. 


l. Requirements for SNAP I and SNAP II Connectivity 
with SPLICE 


Diomeatesoryeot commectivyity exploits the 
distributed processing power between combatant vessels and 
Seeeerh. Karlier the possibility of connecting shipboard PCs 
with SPLICE was explored. The reason this’ possibility came 
to fruition is that AT&T Dimension 2000 PBX (Public Branch 
Exchange) machines have been, or are replacing the old 
Stromberg - Carlson mechanical switch telephone exchanges on 
board ships. What this means is that finally shipboard 
voice grade lines have become reliable enough to support 
data communications. The Honeywell DPS-6 and Harris 
computers are the hardware for SNAP I and SNAP II 
respectively. With the Dimension 2000 PBX, it is now 
possible to link these machines directly into a Tandem 
mainframe when the ships are in port. This connection could 
facilitate online transactions between user terminals 
directly connected through a SNAP I or II user host, to a 
SPLICE server host. Again we have a Situation where the 
Honeywell, Harris, and Tandem terminal management is 
probably incompatible. A software solution would have to be 
effected to allow for full Screen management options offered 
to local Tandem terminals to be available also on SNAP I and 
II terminals. However, a distinct advantage to closing the 
loop between SNAP I, SNAP II, and SPLICE would be the 
feeletyeto directly pass MILSTREP transaetions that 
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presently move through AUTODIN over telephone link or DDN 
TAC link to a SPLICE node. The advantages of doing so dre 
clear. MILSTRIP requisitions and transacttons coulambe 
automatically generated by the SNAP I and II hardware that 
is automatically transmitted to SPLICE nodes with no human 
intervention. The reverse flow of transactions would also 
be true, effecting a more real time update of logistic data 
bases on board ships. 
These transactions would move more quickly through 
SPLICE and the DDN. Present arrangements for transferring 
MILSTRIP transactions from fleet combatants to the stock 
points include the following inefficient variations: 
¢ Flying MILSTRIP transactions in the form of IBM Socm 
and DB form 1348m punched card decks from aircraft 
a teaettte en ena Ss oken an ae Si eene lige Siemon 


¢ Physical delivery of MILSTRIP transactions on magnetic 
tape to an activity with AULODEN “capa cy. 


¢ Physical delivery of MILSTRIP transactions in ene roam 
of etc | ales to an activity with a paper tape and 
AUTODIN interface. 

¢ Transmission of MILSTRIP transactions via Naval Message 
to DAASO (Defense Automated Addressal Systems Office) 
only to be reformatted yet again for transmission 
through AUTODIN. 

All of this is very inefficient, wastes fuel and 
manpower, and is a needless burden to the Naval 
Telecommunications message procesSing system. All of these 
methods are most assuredly slower and less reliable than 
packet switching via SPLICE and the DDN. When pierside, all 
MILSTRIP traffic should henceforth travel from ships to 
Stock Points via direct link to a SPLICE node, or indireas 
link to a SPLICE node via a DDN TAC. Use of Naval Message 
traffic for MILSTRIP transactions should never occur when 
ships are pierSide. The reverse is equally true. All 
MILSTRIP traffic originating from Stuceek = boimrs scmcueler. 
destined for fleet units should be transmitted via SPLICE 


and the DDN whenever ships have a pierside connection. 
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Hopefully, at some point in the future, the MILNET will 
Support satellite transmission of datagrams, allowing all 
logistic data communications traffic to flow through DDN and 
SPLICE while vessels are underway. Until this occurs, it is 
imperative that the Navy's maintenance and logistic 
communities present a united front to DCA demanding such 
Bepability of the MILNET. 


2. Requirements for DLA AIS (Automated Information 
System) Connectivity with SPLICE 


The DLA (Defense Logistics Agency) represents a 
Significant source of both consumable and repair part 
material to fleet combatants. No discussion of global Navy 
material requirements can exclude or minimize the impact 
that DLA plays in supporting the fleet. Heretofore, system 
Wide visibility of DLA material has been limited to major 
commands such as SPCC that enjoyed direct connections to 
SAMMS (Standard Automated Material Management System) 
mieabases at the 6 DLA ICPs. Since fleet material 
requirements supplied by DEA are So wsilgpnificant, it is 
imperative that interprocess operability with DLA be made a 
priority issue. Although there is some limited online 
visibility of DLA material, the entire contract 
administration mission of DLA is presently not visible to 
the Navy Supply System. A hefty percentage of all Navy 
Semeracts are being administered by DLA'’s CAS (Contract 
Administration Service). The actions of the DCASRs (Defense 
Contract Administration Services Regions), DCASMAs (Defense 
Contract Administration Services Management Areas), and 
DCASPROs (Defense Contract Administration Services Plant 
Representative Offices) are not visible at present, and 
there is no method or plan for interdperability. It 
behooves’ the Navy Supply System to gain access to MOCAS 


(Mechanization of Contract Administration Services ) 
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processes if we are to improve our management of contracts 
in which we have vested interests. This is stated in light 
of alleged recent abuses in contracting, and the masSive 
amount of news media exposure given to such occurrences. 

DLA is essentially an extension of the Navy Supply System 
and it is time that it is treated as its integral part, with 
an effort toward achieving fluid interoperability between 
DLA AISs and Navy Supply System AISs. 


3. Requirements for Army, Marine Corps, and Air Force 
Logistic Systems Connectivity with SPLICE 


The same reasons for requiring interconnectivity 
between SPLICE and DLA hold for interconnectivity between 
the sister services logistic AISs and SPLICE. Probably the 
biggest outside customer of the Air Force Logistic system is 
the Navy. This is due to management of aviation repair 
parts common to both services that the Air Force has 
cognizance over. SPLICE needs to communicate with Air Force 
logistic AISs if the Navy is to gain better visibility ame 
control over aviation repair parts. Although not as 
Significant, the requirement for material support from the 
Army and Marine Corps logistic systems are evident in 
Support of day to day combatant vessel requisitions. There 
are a Significant number of repair parts, particularly 
electronic ones that the Army has cognizance for. It 
behooves the Navy Supply System to gain visibility of Army 
material. The reverse arguments are also true. Each one of 
the sister services has a vested interest in gaining 
visibility of Navy material. Repair parts flow freely 
between the services in support of each others' respective 
missions. However, this flow is largely uncoordinated at 
the present time. Interoperability through SPLICE 
represents a vanguard effort to bring these separate 
logistic environments together for enhanced mutual material 


SUPPOLre. 
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4. Requirements for GSA Logistic AIS Connectivity with 
SPLICE 


Often we take for granted and gloss over the vital 
role that the GSA (General Services Administration) plays in 
supplying the Navy with general consumable goods and tools. 
This support is not evident until such time that a vital 
consumable item cannot be procured due to some system-wide 
deficiency. When the paper shortage occurred several years 
ago, everyone was reminded of the role GSA plays in 
Supporting fleet requirements, though the shortage was 
through no fault of GSA. Although they are not a member of 
the DoD establishment, a tremendous amount of material is 
supplied to the fleet by GSA. The GSA AISs are the final 
link that must be hooked into SPLICE to functionally view 
the Navy's material procurement process as a global system 


vice a maze of interrelated, but disjoint systems. 
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V. LONG-TERM REQUIREMENTS FOR TRANSPARENT INTERNETWORK 
CONNECTIVITY THROUGH SPLICE 


The requirements cited in the previous chapter will 
Simply enable differing user terminals and hosts on 
different systems to communicate with SPLICE nodes in a 
normal manner. In other words, the requirements basically 
deal with the problems of connection and translation, 
allowing one system to speak to another. This chapter 
addresses issues that take the concept of transparency quite 
a bit further. The true maturation of a distributed pa 
lies in the ability to login to a terminal, and execute 
system-wide transactions without concern for the machine and 
the geographical location which is Servicing the user 


Reaves fa. 


A. AN ANALOGY BETWEEN EARLY 3RD GENERATION 
HARDWARE/ SOFTWARE AND PRESENT STATE OF AFFAIRS 


A rough analogy of where Navy Supply Corps AISs 
currently stand vis-a-vis the potential of mature 
distributed systems follows. Imagine that we are dealing 
with beginning third generation hardware and third 
generation languages. The tools provided us are far 
superior to the old solid state machines such as the 
AN/UYK-5(V). The use of a third generation language such as 
COBOL has released us from the necessity of knowing how data 
is handled internally (as was the case in assembler 
programming) and an operating system such as IBM's OS/MFT 
allowed us the luxury of multiprogramming. However, input 
functions, output LEumetionse TleTeELese lan of files, | 


location of files, detailed physical description of file 
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formats, their location, peripheral devices used, compiling, 
linkage editing, loading, job step executions, etc., must 
all be explicitly defined and stated. The user, programmer 
in this case, has to have intricate knowledge of the 
physical hardware setup as well as the software he is 
working with to successfully execute a batch job. Compare 
Mies scenario from not so long ago to that found on 4th 
generation hardware and operating systems, notably VM/CMS. 
Under such an operating system, you have what appears to be 
your own machine, you are no longer burdened with the 
physical details of peripheral devices and the storage of 
data. The programmer is liberated to concentrate on the 
problem of writing a correct program. The operating system 
assumes responsibility for the details of file storage and 
retrieval. All the user has to do is name the files, write 
them, and read them. Of course it is not quite so simple as 
Memeerayed here, but it is a quantum leap over the rigors of 
JCL and COBOL's Environment Division specifications. 

We are still at the stage where detailed processes and 
machinery in the form of hosts must be explicitly stated. 
If it 1S a remote host, we must login to it before execution 


of any further processing. 


Pee ONCTELONALLY RELEVANT DETAIL IN A DISTRIBUTED SYSTEM 


Consider, if you will, how long American Airlines would 
be able to compete if their passenger reservation system 
required reservation personnel to identify explicitly which 
process at which location controlled the passenger 
reservation file for flight number 624 from Philadelphia to 
Detroit on 24 October 1985. Let us assume that there are 
several hosts in the AA reServation system, and that these 
hosts are distributed, as they most certainly are. The 


system would not last long because AA reservation personnel 
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would soon be relieved of the burden of such worrisome 
detail. United, Eastern and TWA would be doing it for them. 
Fortunately for AA, the reservation personnel need not 
concern themselves with such details. They are only 
concerned about functionally relevant data such as flight 
number, date, source of origin, destination, passenger 
names, etc. The system responds to these functionally 
relevant demands. It does not burden the reservation 
personnel by requiring them to identify explicitly the 
correct remote server host, execute an additional login 
procedure, specify the processes to be invoked to satisfy 
the functional request, etc. In large part, the beauty of 
such a distributed online system is a direct result of 
fierce competition between the airlines. 

The BT3 (Boiler Technician 3rd Class) Supoly Petre, 
Officer for B Division on board an ADAMS class DDG doesn't 
have such a system to work with. Nobody is competing with 
the Navy Supply System, and it is the only show in town. 

Not quite, when the chips are down, his compatriots will 
abandon that system and opt for extenSive and expensive 
repair of a valve vice replacement. Or his boss, the Chief 
Engineer, will get the local IMA (Intermediate Maintenance 
Activity) to buy off on a C-2 or C-3 CASREP and get a new 
part manufactured by one of the local commercial machine 
shops around the waterfront. The required parts may have 
been sitting in a bin down in the Supply Support (Genter iam 
Sitting on a shelf at NSD Yokosuka, but they were never 
adequately identified. The parts may as well have never 
been procured and stocked by the Navy Supply System. As far 
as the BT3 and the Chief Engineer are concerned, they do not 
exist, and for all practical purposes, they don’t! In 
either case, the Navy will pay dearly for parts that might 
have been identified, requisitioned, and delivered by the 
Navy Supply System in the same or shorter time than might be 


needed to overhaul or manufacture the parts. 
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Here are the relevant functional questions that any 
person directly supporting a maintenance and repair effort 
will have when a parts requirement has been identified: 

e What is the part that I need? 

e Where can I get it? 

¢ How long will it take for delivery? 

Due to time and space constraints, we will limit this 
discussion to the first functionally relevant question. 
Solutions to the second and third question follow the same 
line of reasoning presented below for the first question. 

In this generic shipboard situation, often the most taxing 
exercise in requisitioning a part is the basic problem of 
its definitive identification. For anything but the most 
routine and mundane identification problem, a substantial 
amount of technical expertise and minutia is involved. The 
problem is exacerbated if the ship's COSAL (Coordinated 
Shipboard Allowance List), technical manuals, and drawing 
numbers are out of date, incomplete, inaccurate, or worst of 
all, nameplate data from the failed part cannot be read or 
1s unavailable. There are a variety of methods for 
definitive identification of a repair part, and a good SKl 
(Storekeeper First Class) can proceed by several methods. 
Most all of these methods are time consuming, and there is 
no guarantee that a given ship has a sharp SKl or SKC on 
board. It has been known not to be the case. Often, the 
mae BIS Supply Petty Officer for B Division will be more 
adept at identification of parts germane to B Division than 
Storekeepers in the Supply Support Center. The BT3 may have 
been at this job for just under four years. He walks around 
with a logbook full of part numbers and National Stock 
Numbers that he painfully identified over the last three and 
a half years. B Division will greatly miss this BT3 if he 
gets transferred, leaves the Navy, or fails to pass on his 


logbook and his corporate knowledge before departure. 
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There is a systemic problem with parts identification 
and parts requisitioning. It is too labor intenSive and too 
complicated for most supply personnel, let alone maintenance 
personnel, to learn proficiently. It is probably one of the 
most "user unfriendly" systems ever developed. Higher 
authority can insistently admonish that "A rigorous training 
program must be adhered to in order to overcome these 
technical difficulties and make the system work!" However, 
time and manpower resources are scarce commodities on board 
Ship. The BT3 should have spent 4 years repairing equipment 
and learning his rate, not learning to become a storekeeper. 
How can we reverse this situation? The system must support 
user friendly global research capabilities for parts 
identification. This starts with hardware and software for 
SNAP I, SNAP I1, and SPLICE sites tn direct suppereeas 
maintenance activities. For starters, the COSAL needs to be 
loaded into an online DBMS. Secondly, at a bare minimun, 
microfiche publications such as the ML-N (Management List 
Navy) and the MCRL (Master Cross Reference List) must also 
be loaded into a DBMS. a Parts Identification Modulesnaes 
be implemented which will step the novice user through to a 
successful identification of the required part. A 
storekeeper should not have to help him. 

Let us assume for the moment that such a Parts 
Identification Module has been implemented in SNAP I and II. 
Such a system would require complex menu selection 
facilities and user prompts to extract as much informabeam 
as possible that the user may possess about the problem at 
hand. Even the best expert system will not be able to 
identify all parts, particularly in cases when material is 
obsolete, no longer manufactured, or the ship's COSAL does 
not reflect a specific piece of equipment. The shipboard 
computer can only handle so much data. The three documents 
COSAL, ML-N, MCRL, are only a small subset of the technical 
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data available to identify parts. We must be able to go 
further through automation when SNAP I and II cannot handle 
an identification request. The request must be passed off 
through SPLICE to a suitable system or combination of 
systems that can satisfy the request. Powerful parts 
identification capabilities are available from the Supply 
Centers. Even more powerful facilities are available from 
Moe) (Defense Logistics Services Center) and SPCC (Ship's 
Parts Control Center). These activities by no means are the 
only tools available. The other armed Services have their 
own capabilities which would be of great benefit when 
material under their cognizance is being researched. These 
capabilities do the BT3 no good unless he can invoke them. 
Now let us further assume that there are Sophisticated 
Parts Identification Modules available at the Naval Supply 
Centers, the ICPs and DLSC. DLSC used to Support a 
rudimentary Service whereby a part number requisition could 
Bemsubmitted via AUTODIN, and within 48 hours or so, DLSC 
would reply with an NSN (National Stock Number) that it 
successfully cross referenced. Obviously a much more 
Sophisticated and general Parts Identification Module would 
be required, with response in the order of minutes if not 
seconds. We must do this through SPLICE and the DDN. The 


question is, how? 


fe IMPLEMENTATION OF A DDS (DIRECTORY/DICTIONARY SYSTEM) 
FOR TRANSPARENT INTEROPERABILITY 


To implement interoperability between modules located on 
differing systems at different nodes, the names and 
addresses.of these modules must be identified. We assume 
that the request is handled in the same manner that the Navy 
handles its maintenance effort. We have a three tiered 


system starting.on the bottom with the "Organizational" 
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level in direct support of the user, the "Intermediate" 
level which would handle requests beyond the scope of SNAP I 
or SNAP II, and a "Depot" level which would handle the most 
complicated requests by size and scope. 

SNAP I, SNAP I1, and SPLICE sites im direct ‘Supportwas 
maintenance effort should provide organizational level parts 
identification capability. Due to hardware and peripheral 
device constraints, the data base available for such 
processing will be limited in scope, perhaps to the three 
tools cited earlier. If the SNAP I or II Parts | 
Identification Module fails in its search, it should then 
notify the user, attempt to gain additional information, and 
prepare to send the request to a remote server host 
possessing a Parts Identification Module with enhanced 
intermediate capabilities. Requests beyond the scope of a 
Parts Identification Module with intermediate level 
capability would be referred to a depot level Parts 


Identification Module. 
1. A Process Resource DDS Imolementaci on Seno 


In the most recent SPLICE repomiapreparcaapy 
Schneidewind and Dolk [Ref. 29], the concept of a DDS is 
introduced. The most basic DDS should be implemented in 
SNAP I, SNAP II, and lesser SPLICE sites. In the particular 
case at hand, consider a Situation wherein a SNAP I or II 
Parts Identification Module is unable to Service an 
identification request due to lack of technical resources at 
hand. Given that the request is in the correct format, and 
has been validated as potentially solvable, the Parts 
Identification Module would "process resource fault" in the 
Same manner aS an operating system "page fault" in a virtual 
memory Situation. - 

The term "fault" here does not indicate an error or 


a defect. The term stems from virtual memory operating 
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System architecture. In a virtual memory implementation, a 
"page fault" occurs when an executing process requires data 
that is not immediately available in RAM (Random Access 
Memory). The operating system must then fetch and read into 
RAM a "page" of data from secondary storage, typically a 
disk drive, before the process can continue executing. 

A similar "fault" concept is presented here for 
distributed processing. If data required is not available 
locally, it must somehow complete the executing process by 
either fetching the information from some other node in the 
internetwork environment, or by transferring control of the 
entire process to another node possessing capability for 
complete execution of the interrupted process. The “process 
resource fault" would cause the Parts Identification Module 
to pass control to a Resource Fault Module. The ReSource 
Fault Module would query the local DDS for information as to 
where to refer this ''process resource fault” for further 
execution. The local DDS would provide this information and 
the Resource Fault Module would then execute an 
"internetwork call" to a remote server host identified by 
the local DDS as having capability for servicing the request 
at hand. Appropriate parameters would be passed to the 
Server host process as part of the "“internetwork call." In 
this case, a logical remote server host would be one of the 
Supply Centers. Presumably the SNAP I or II system would 
have some knowledge of the location where it is operating. 
In this manner, a request would not be directed to NSC 
Norfolk when the ship is located in Subic Bay. 

But what happens when the local SNAP I or II DDS 
does not contain the information necessary for correct 
mi erral of a2 process resource fault’? DGhe situation is 
solved by the local DDS indicating so to the Resource Fault 
Module, while concurrently providing the address of a remote 


Server host possessing an intermediate level DDS. State 
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information currently held by the Resource Fault Module is 
saved, and the entire request including the "process 
resource fault'’ state information is referred to a remote 
host with an intermediate DDS through an "internetwork 
ead lee 

In the process resource DDS implementation scheme, 
the entire process of identifying a bogus part was "passed" 
via an "internetwork call” to a remote Server hostew rene 
resident intermediate Parts Identification Module. [In the 
case of a valid but more obScure request, the local DDS 
might not have the directory/dictionary information 
necessary to properly refer the request. In this case, the 
entire process of identifying the bogus part is "passed" via 
an "internetwork call" to a remote server host with an 
intermediate level DDS. This DDS will hopefully contain the 
directory/dictionary data necessary for proper referral of 
the request. When the intermediate Parts Identification 
Module “process resource faults” for lack of processing 
capability, the request is referred to a depot level Parts 
Identification Module. If the remote server host DDS or an 
intermediate level DDS cannot properly refer the "process 
resource fault," the entire process is referred to a depot 
level DDS. The relationship between organizational 
processes/DDS and intermediate processes/DDS are analogous 


to intermediate processes/DDS and depot processes/DDS. 
2. Physical Location of Hierarenreale Dis 


Schneidewind and Dolk offer two extreme alternatives 
as to degree of distribution for the DDS [Ref. 29: 
p. 65, 66], as well as a compromise implementation. Herein, 
it is proposed that a three tiered hierarchical DDS also be 
implemented. The most rudimentary DDS shall be installed in 
all SNAP I, SNAP I1, and minor SPELG@R esate Instavetrronce 
Intermediate level DDSs should be implemented at NSC Pearl 
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moepor, HL; NSC Oakland, CA; NSC Norfolk, VA; and NSA 
Naples, Italy. The intermediate level DDSs should be able 
to handle all directory/dictionary referral requests that 
cannot be handled by the organizational level DDS at SNAP I, 
SNAP II and lesser SPLICE sites. Online storage 
requirements and activity level will determine if 
intermediate level DDS facilities should be implemented at 
all of the Naval Supply Centers. The intermediate level DDS 
memnd be able to direct all requests that potentially can 
be serviced by a module somewhere within the confines of the 
Department of the Navy. Depot level DDS facilities should 
be located at the ICPs, SPCC and ASO (Aviation Supply 
Office) respectively. These depot level DDSs should be 
capable of directing all requests outside the purview of the 
Department of the Navy, to modules resident at remote server 
hosts offered by DLA, sister services, and GSA. The DDS 
hierarchical demarcation lines are very arbitrary at this 
point. They can and will be restructured to fit the 
Situation as it develops during implementation. 

The rationale for location of intermediate DDS 
facilities for such modules is to service each Fleet. 
Although NSA Naples is not is considered a major stock 
point, it represents the hub of all Sixth Fleet logistics. 
To refer all Sixth Fleet directory/dictionary referral 
requests to, say, NSC Norfolk in CONUS is considered to be 
unacceptably inefficient. Perhaps the DDS located at NSC 
Pearl Harbor should be moved closer to Seventh Fleet action, 
say, NSD Guam. Furthermore, it may prove expedient to 
install an intermediate DDS facility at Diego Garcia, BIOT. 
In any event, what iS envisioned is a hierarchical DDS 
architecture. When a lower level DDS is incapable of 
directing a "resource fault" to a remote server host, the 
lower level DDS will pass parameters indicating this to the 


local Resource Fault Module, and Specify the address of the 
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next higher DDS facility in reasonable proximity. It shewmia 
be emphasized that the intermediate and depot level DDS host 
in most cases will not have the capability for handling a 
user host "resource fault." Higher level DDSs provide 
detailed maps of system resources. The resident Resource 
Fault Module at the intermediate or depot DDS uses this 
information as well as the “resource fault" state 
information passed to it from the user host, and directs the 
"resource fault" to an appropriate remote server host 
through an "internetwork call.” In this particular case, we 
are interested in only the location of hardware, software 
and data required for satisfying the “resource fault.” The 
total content of what the DDS offers is much larger in 
Scope, and the reader is referred to Schneidewind and Dolk 
[Ref. 29: pp. 58 thru 64]. | 


3. <A Data Resource DDS Implementation Scheme 





One of the fundamental assumptions in the 
organizational level Parts Identification Module scenario is 
that the entire process that "process resource faults” is 
kicked up to the next higher level server host process via 
an "“internetwork call." The user host simply waits while 
higher level processes at remote server hosts take control 
of the entire request and execute it to completion. When 
process execution is completed, the results are transmitted 
back to the user host. It is not efficient for SNAP IT Yous 
to maintain control over a process that has "resource 
faulted" for lack of data. The cost of communication 
overhead between a shipboard SNAP I or II process and data 
resources scattered throughout the system would be too 
great. Therefore, the SNAP I or II system will "process 
resource fault" whenever required data is not locally 
available, regardless of whether local processing capability 


exists for execution to successful completion. The Tandem 
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TXPs at SPLICE sites have much more procesSing power, have 
Superior data communication lines and facilities, and they 
are designed for tranSactional processing. It is assumed 
that the SNAP I and II sites do not possess the processing 
capabilities or the high speed data communication 
connections that will be required for more complex 
processes. The data communication lines between SNAP I and 
IL sites must be assumed tenuous at best, and can be broken 
at any moment due to operational necessity or by the very 
nature of the pierside environment. If an entire request is 
referred to a higher level process ashore, then even if 
connection is broken unexpectedly, results can be spooled 
emer Cransmitted to the ship at such time that data 
communications are reestablished. 

Let us now dissect the DDS scheme from a data 
resource point of view. In this situation we will assume 
that an intermediate level Parts Identification Module at 
NSC Jacksonville is handling a process referred from the USS 
FORRESTAL (CV 59) which "process resource faulted." In this 
example, the intermediate level Parts Identification Module 
will be in control throughout execution of the request to a 
successful conclusion. It will not "process resource fault" 
to a depot level Parts Identification Module. However, in 
the process of Servicing this request, the intermediate 
Parts Identification Module will "data resource fault" for 
data not locally available. For the sake of argument, let 
us assume that it requires a copy of APL 841800019 and the 
piece identification table included in NAVSEA drawing number 
805-1349742 revision 3. Thus two "data resource faults” 
Peel occur. 

The first "data resource fault" will occur to 
extract a copy of APL 841800019 from the WSF (Weapons System 
File) at SPCC Mechanicsburg. The intermediate Parts 


Identification Module would Signal a "data resource fault" 
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to the resident Resource.Fault Module. The locally resident 
DDS would indicate to the Resource Fault Module, that the 
information required is in the WSF at SPCC. The Resource 
Fault Module would execute an "“internetwork call" to the 
SPCC SPLICE complex requesting a download of that particular 
APL from SPCC. The file containing that APL) is success inuee, 
downloaded, and the "data resource fault" that precipitated 
this downloading process is satisfied. In the future, each 
Supply Center may actually hold an online copy of all APLs, 
but for the sake of illustrating this point, we assume that 
a copy must be downloaded from SPCC. 

In the second "data resource fault situation seme 
"data resource fault is passed fo the resident  Resomiee 
Fault Module. The Resource Fault Module queries the local 
DDS to see where NAVSEA drawing number 805-1349742 revision 
3 can be found. The local DDS indicates to the Resource 
Fault Module that it cannot generate that data. It 
indicates to the Resource Fault Module that it should direct 
this query to the intermediate level DDS located at NSC 
Norfolk. The Resource Fault Module executes a "data 
resource fault" "internetwork call" which includes pertinent 
State parameters to the DDS resident at the NSC Norfolk 
SPLICE complex. The NSC Norfolk Resource Fault Module takes 
this request and executes the query against the intermediate 
level DDS. The intermediate level DDS is also unable to 
generate a solution. Now the highest level DDS "data 
resource fault" occurs. The NSC Norfolk intermediate DDS 
indicates to its resident Resource Fault Module that it must 
pass the query to the depot level DDS at SPCC Mechanicsburg. 
So the NSC Norfolk Resource Fault Module executes an 
"internetwork call" to the SPCC Mechanicsburg depot level 
DDS, concurrently passing relevant state information about 
the user request process that originally "data resource 
faulted" at NSC Jacksonville. The SPCC Mechanicsburg 
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Resource Fault Module takes this request, and queries the 
depot level DDS for a solution. The depot level DDS 
indicates that the information required is located online at 
Long Beach Naval Shipyard. The SPCC Resource Fault Module 
then executes an “internetwork call" to the SPLICE site at 
Long Beach Naval Shipyard directing it to transfer the file 
that contains the piece identification table for NAVSEA 
drawing number 805-1349742 revision 3, to the process in the 
user host at the NSC Jacksonville SPLICE site that “data 
resource faulted" for this information. 

The intermediate Parts Identification Module at NSC 
Jacksonville now has both "data resource faults" satisfied, 
and iS now in a position to resume execution. Happily, it 
finds that NSN 7G 4320-00-237-4861 is the solution to the 
parts identification query originally passed from the USS 
FORRESTAL (CV 59). The NSC Jacksonville Resource Fault 
Module then executes an "internetwork call" to pass this 
information back to the SNAP I process on board FORRESTAL 
which generated the "process resource fault" that started 


this procedure. 
4. Implementation Considerations 


The process and data “resource fault" procedures 
cited above illustrate a possible implementation for 
transparent execution of complex processes requiring system 
wide resources in dispersed and varying locations. The 
author does not intend to imply that the processes cited 
above are the correct technical method of solving the 
problems illustrated. Such is a systems analysis problem. 
What is intended, 1s to focus on a general methodology for 
execution of such transactions. Obviously, in some 
Situations, a DDS will respond that requested data is simply 
not available, or that data is available, but in hard copy 


form. Such a scenario would require human intervention and 
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manual review. Early implementation of a Parts 
Identification Module would be fraught with "data resource 
faults" where the DDS indicates that the data is not online, 
but is in hard copy format. However, until such transparent 
Systems modules are implemented, it will be difficult to 
identify all logistic data that should be digitized and 
online. Not everything can be brought online at once. [It 
is an evolutionary process. Once such systems are up and 
running, the most critical data not online will Gqugekigese 
identified for digitization. Depending upon the priority of 
the requisition, a threshold for manual review would have to 
be established. It is recognized that there is potential 
for a lot of abuse of such a system through users 
unwittingly cauSing maSSive and complex searches to be 
executed. The user interface and validation modules for a 
Parts Identification Module must attempt to Screen out such 
requests and limit processing to valid and potentially 
solvable problems. Through similar implementations, the 
other two functionally relevant questions could also be 
transparently automated. Of course, there is no limit to 
the number of processes that could be supported. The 
ultimate criteria for deciding which applications to 
implement first will be projected return on investment 
measured by that universal yardstick, improved material 
readiness on board ships. It is the author's belief that 
work should commence to design such internetwork transparent 
processes to exploit the benefits of SPLICE and to bring a 
user friendly revolution to the end users of the Navy Supply 
System, the BT3, the AMS2, and their compatriots. 
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Vee ker RRA OF MILSTRIP REQUISITIONS IN A DISTRIBUTED 
ENVIRONMENT 


One of the problems presented by radical changes in 
automation is a realization that the most efficient method 
of accomplishing an objective is not simply to streamline 
and automate a manual system. Sometimes, it iS necessary to 
take inventory of the tools and resources available, 
reassessing the best method for getting from point A to 
point B with these new tools. Since we are in the dawn of a 
distributed processing revolution in the Navy Supply Corps, 
it is time to take a look at the fundamental process of 
MILSTRIP requisition processing. In particular, the 
MILSTRIP referral process. At the present time, when an end 
user submits a requisition to the local stock point, Several 
things can occur. These actions are summarized below. 


* The UADPS-SP process _ checks to see if:the NSN in 
g@aestion is carried locally in stock. 


* If the NSN is carried, and the quantity on hand meets 
the demand, a material release order iS cut to satisfy 
the requisition. 

¢ If the material is not carried, or there is not enough 
Stock on hand to satisfy demand, the requisition is 
referred to the ICP. 

* The ICP examines the requisition, checks to see where 
this particular material is stocked, and once again 
refers the requisition to an eueroR aie S stock point 
believed to have on hand stock of this 

In the event of a referral to the ICP, this referral 
process from the stock point to the ICP and vice versa often 
takes on the characteristics of a recursive function as the 
ICP vainly searches for a stock point that carries the 
material demanded. Why does this recursion in the referral 
process occur? Because the ICP does-not possess real time 
information about the inventory level at the stock points, 
or the inventory records that the stock point reflects are 


iimaecturate . 
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Normally these requisition referrals traverse through 
ICPs and stock points via AUTODIN. So the process is not 
exactly what could be referred to as occurring with blinding 
speed. Anyone who has spent any time tracking MILSTRIP 
Status knows that on the average, it takes at least a day 
for a requisition, even if it is Issue Group I, to traverse 
an ICP or a stock point during the referral process. It 
doesn't have to be this slow. With SPLICE and the DDN, 
there is no longer a fundamental reason for referring all 
requisitions to the ICP when frustrated at a stock point. 
Through packet switching, it is possible to refer 
requisitions from one stock point to another with great 
speed. The old line of reasoning is that the ICP is the 
only organization that has the overall visibility of stock 
throughout the Supply System. Therefore, it appears logical 
to refer all frustrated requisitions to an ICP for proper 
routing. This made good sense in a 1967 batch processing 
environment. Thus we have centralized management of 
resources. This argument no longer holds true today. The 
Tandem NonStop TXPS are extremely powerful transaction 
machines. The capacity of disk storage has increased 
tremendously since the IBM 2314 disk drives, and the cost 
per byte stored has fallen drastically. There is no reason 
that the NIR (National Item Record) cannot be loaded into 
disk storage at every major stock point, certainly all the 
NSCs and NSDs. It could be set up in a very Simple indexed 
format illustrated by Figure 6.1. There is of course no 
physical limitation to implementation of an index along the 
same lines as that illustrated in Figure 6.1. Every major 
Stock point should be capable of intelligently referring 
requisitions without EGP intervention af sien 40 eiade as 
loaded online. ' 

The NIR Referral Index is indexed by NIIN (National Item 
Identification Number). For each NIIN, The RICs (Routing 
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Breure 6.1 Example of a Stock Point NIR Referral Index. 


Identifier Codes) would be listed in descending order of 
probability of successful referral. This means that the 
stock point with the greatest stock on hand would be first 


on the list, and those stock points with only one each on 


hand would be listed at the end of the RIC list. A referral 


algorithm based upon probability of successful referral, 


proximity, and other factors could be developed quite easily 


to govern rules of referral. 


Pewee LMPLEMENTATION OF A STOCK POINT NIR REFERRAL INDEX 


Let us assume that all of the NSCs and NSDs implement 
Miemean index. When a requisition 1s frustrated at the 
meoek point of origin, SPLICE will package the requisition 
maa TOP (Transmission Control Protocol) segment for 
referral to the next logical stock point indicated by the 
NIR index and routing algorithm. At the end of the data 
Segment, behind the MILSTRIP data, the RICs of all stock 
points traversed by this MILSTRIP document would be 
appended. Thus each MILSTRIP transaction now carries its 
history of traversal with it. By examining these RICs 


before further referral, the next stock point will not cause 


the requisition to be referred back to a stock point that it 


has already visited. Thus, the recursive referral problem 


Td, 


is avoided. After an arbitrary number of RICs are appended 
to the end of this TCP segment, perhaps 8, SPLICE would then 
automatically refer this requisition to the appropriate ICP 
for further processing, or manual review. The ICP column in 
Figure 6.1 can of course be substituted with the COG 
(Cognizance Symbol). If the COG is used vice the ICP RIC, 
another index would be required to translate the COG to a 
RIC prior to transmission. This is an implementation 

det andr. 


B. ADVANTAGES OF IMPLEMENTING A STOCK POINT NIR REFERRAL 
INDEX 


There are three major advantages to implementation of 
such a referral scheme. First of all, this method of 
dynamically routing requisitions between stock points 
relieves the ICP computer systems of a tremendous workload. 
At the same time, the workload at the SPLICE sites is 
increased only marginally. 

secondly, transmission of MILSTRIP documents Dy pacer 
Switching through the DDN is much faster, more reliable, and 
more efficient than transmission via AUTODIN. The end 
result is movement of material to the fleet in a more seams, 
fashion. 

Thirdly, such an implementation would foster much needed 
redundancy throughout the Navy Supply System. Presently, 
operation of the entire Supply System is hostage to the 
referral processes at SPCC and ASO. In a wartime 
environment, this could prove disastrous. Using the 
distributed processing tools offered by SPLICE, and the 
redundancy built into the DDN, we can break the yoke of such 
a centralized and vulnerable mode of operation. If the NIR 
index were implemented at all of BS qe jier stock points, ASO 
and SPCC could both be destroyed, but MILSTRIP referrals 
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would continue to traverse through the Supply System via 
PELICE and the DDN. 


C. DISADVANTAGES OF IMPLEMENTING A STOCK POINT NIR REFERRAL 
INDEX 


The obvious disadvantage to implementation of a NIR 
Referral Index is the cost of disk storage space to 
implement such an index. In order to make it truly 
redundant in a wartime environment, an abbreviated copy of 
DLSC's (Defense Logistics Services Center) NIR should be 
loaded on disk. If it were intelligently formatted, it 
would likely require anywhere between one and two 512 
megabyte disk drives. Obviously there is more processing 
overhead involved at the stock points in looking up each 
frustrated requisition in the NIR index. However, the 
Tandem NonStop TXP machines were designed for such 
functions, so it should not be much of a problem. 
Periodically, the ICPs would have to promulgate changes to 
the NIR index, so that all of the stock points are using 
uniform and current information. The major overhead would 
be in initially loading such an index, maintenance of it 
Should prove not very taxing. As a final note, Special care 
must be taken to implement the "TCP Quiet Time Concept” 
discussed in Appendix B. This special TCP implementation 
must be adhered to in order to avoid duplicate MILSTRIP 


transactions traversing the Supply System. 
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VII. SPLICE INTERPROCESS CONNECTIVITY IMPLEMENTATION TSS 


. AND CONCLUSIONS 


In the previous three chapters, we have seen how SPLICE 
will fundamentally change the way we shall conduct business 
in the near and long term. Here, some implementation issues 


are raised. 


A. EXPAND/X.25 VERSUS TCP/IP DDN VIMPLEMEN wee 


Chapter II mentioned DDN's current inability to support 
IBM SNA SDLC terminal communications and Burroughs 
Bisynchronous Poll/Select terminal communications. A 
possible solution to this problem is the implementation of 
Tandem Corporation's off the shelf EXPAND communications 
software which uses the services of the CCITT K.25 standard. 
, For a detailed explanation of the CCETT X.25 standacdiea. 


reader is referred to Appendix A. In DDN parlance sea 


CCITT X.25 standard is referred to as “Basie K-25. ~)oRn 
will soon implement an X.25 version that will adhere to 
military Specifications. This mibvearrzeds...- 
implementation is referred to as "Standard X.25." Tandem's 


EXPAND software communications package runs on top of "Basic 
X.25." “Basic X.25" service will be supported by the DDN 
until at least 1] October 1988, but soon thereafter it will 
Support only "Standard X.25" service [Ref. 30]. Through the 
use of other utility programs offered by Tandem, namely SNAX 
and SNAFU, supposedly these synchronous and bisynchronous 
terminal incompatibilities with the DDN can be solved. 

The logical solution for terminal communications would 
be the implementation of TELNET (Network Virtual Terminal 
Protocol) [Ref.-31] which rides above TCP/IP (Transmission 
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Bentroi Protocol/Internet Protocol) [Ref. 32,33,34]. 
Appendix B contains a detailed discussion and overview of 
TCP/IP implementation. The stumbling block to 
implementation of TELNET is the fact that it only supports 
asynchronous terminal communications. As stated in Chapter 
II, DCA intends to implement an IBM 3270 bisynchronous 
meaeocol, but no plans are made for implementation of IBM's 
SNA SDLC. This is a most unfortunate situation. Regardless 
mee DCA s stand on this issue, IBM SNA SDLC is rapidly 
becoming the industry de facto standard. Ignoring this fact 
only handcuffs current IBM SNA SDLC implementations in the 
DDN, and sours any future desire by DoD customers to 
implement the DDN. The DDN is the DoD mandated common 
Switched data network. It is a monopoly service for DoD. 
Therefore, the users have no choice but to put up with 
whatever inconveniences it causes. It is the author's 
concern that delays in delivering compatibility with current 
commercial industry standards may eventually lead to 
substandard service for DDN users. A change in the DCA 
policy with respect to the IBM SNA SDLC issue will send a 
Signal to its customers that it intends to continue 
Supporting innovative commercial Services about to become 
industry standards. DCA's current position is that in 
Megdttten to TELNET, it will support IBM 3270 BSC (Binary 
Synchronous Communications) DSP (Display System Protocol) 
[Ref. 30], but will not develop support of any other 
Synchronous protocol. AS was mentioned in Chapter II, 
bisynchronous communications are being rendered obsolete by 
Synchronous communications. DCA's present support for IBM 
BSC DSP is sound, but the author fears that this is becoming 
an aged technology. The DCA, as this author sees it, should 
stay ahead of its customers’ demands~rather than react to 
them. It is recognized that implementation of the DDN is a 


tremendous task and that there are fombliecerme Prrvorities in 


81 


the overall scheme of implementation that severely tax the 
financial and personnel resources of DCA. However, the. 
burden should not be placed upon the customer for 
development of an IBM SNA SDLC protocol specification. This 
is what DCA is currently requesting from NAVSUP in response 
to demands for IBM SNA SDLC support. The general view is 
that IBM SNA SDLC will become widely accepted. The author 
feels that DCA should react accordingly. We are not dealing 
with some unique protocol that some lesser organization 
developed. Recognition must be given to the fact that in 
this instance IBM is again setting an industry standard: 
Delays in giving Support to this quickly emerging standard 
for terminal communications may be a disservice to DDN 
CUSTOMC rs. 

As a result of this IBM SNA SDLC situation, NAVSUP ds 
seriously considering implementation of EXPAND over ‘Basic 
X.25" concurrent with an implementation of TCP/IP. This an 
acceptable stopgap measure, but only until such time IBM SNA 
SDLC is supported by the DDN. Use of TELNET or a DDN 
standard protocol is much more desireable than locking 
SPLICE into use of EXPAND/X.25. Before such a move is 
executed, NAVSUP should take a very serious look at just 
what its IBM SNA SDLC user terminal to remote server host 
demands will be. If it cannot identify some very urgent 
application requirements that would be actively used the day 
Such service became available, perhaps it should instead 
push for a DDN IBM SNA’ SDLC preteco les candace: 
application programs have yet to be developed before user 
terminal to remote server host communications become a 
necessity, then NAVSUP should definitely wait the situation 
out and lobby hard for a DDN IBM SNAVSDECG Vso lution. 

Although concurrent implementation of EXPAND/X.25 and TCP/IP 
sounds inviting, it is fraught with software engineering 
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B. SOFTWARE ENGINEERING QUALITY ASSURANCE FOR DDN 
INTEROPERABILITY 


The most significant problem with implementation of 
EXPAND lies in the danger that application programs may be 
developed that will be coupled to EXPAND internal software, 
an undesireable software engineering Situation. If this 
happens, applications software will inextricably, be tied to 
Tandem Software and consequently Tandem Hardware. SPLICE 
will foster a variety of new applications software. Every 
effort should be made to ensure these application modules 
interface with DDN standard higher level protocols, 
specifically TELNET (Network Virtual Terminal Protocol) 
Meer. 31}, FIP (File Transfer Protocol) [Ref. 35], and SMTP 
(Simple Mail Transfer Protocol) [Ref. 24]. By pursuing such 
a course of action it will be possible to reap the benefits 
of interoperability with other diverse logistic and 
nonlogistic systems in the future. An acceptable interim 
solution to this problem would be development of Server 
modules that provide TELNET, FTP and SMTP specification 
interfaces for applications. How Tandem chooses to make 
these server modules work would no longer be that important. 
The services of TCP/IP or EXPAND/X.25 could be used by the 
Server modules and standard interface integrity of 
application modules would be maintained. With standard 
TELNET, FTP’ and SMTP interfaces, all application modules 
developed would be assured of interoperability with 
replacement hardware that offers the DDN protocols. Through 
use of the higher level DDN protocols and their interfaces, 
SPLICE applications would be insulated from coupling with 
Tandem or any other vendor-specific software. The Navy 
would not be dependent on a sole Source vendor when time 
comes for resolicitation and replacement. Ensuring smooth 


software interfaces with DDN protocols must be the 
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overriding criteria in choosing an end-to-end reliable 
connectivity plan. For reasons cited in the three previous 
chapters, it is crucial that all software from this point 
forward be developed with standard DDN protocol interfaces. 
SPLICE has an obligation to ensure that interoperability 
with SNAP I and SNAP II can be effected smoothly. These 
requirements are starting to appear on the horizon. 
NAVMASSO (Navy Management Systems Support Office) wale 
certainly not implement EXPAND/X.25 for a SNAP I or SNAP II 
interface with SPLICE. The interface will often be through 
direct communication link from SPLICE server host to the 
Ship user host, but this will not be the case when a ship 
pulls into any of a number of foreign ports. DDN will 
Service such data communications, so DDN protocols will be 
required. Such is the only method by which the Navy, let 
alone DoD logistic communities, can ever hope to avoid the 
"Tower of Babel" syndrome. 

If standard DDN protocol software interfaces are not 
developed and utilized, there will be little hope for 
achieving true interoperability when the rest of the Navy 
and the sister services begin implementing their distributed 
systems during the next decade. The Navy Supply System has 
a vested interest in interoperability. DLA or GSA will not 
suffer if there is no interoperability since they acomugn 
the Navy's customers. The Navy is their customer. 
Likewise, the Navy is also a customer of the sister services 
and vice versa. The foundation must be built now for 
interoperability with logistic as well as nonlogistic AISs 
that will follow SPLICE'’s debut on the DDN. This will be 
difficult to achieve if SPLICE application programs are 
developed or modified with EXPAND interfaces. 


~ 
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C. RAMIFICATIONS OF CONCURRENT IMPLEMENTATION OF 
EXPAND/X.25 AND TCP/IP 


Concurrent implementation of two end-to-end reliable 
interconnectivity protocols at the same time can only result 
in software engineering as well as performance problems. To 
begin with, two distinct sets of protocols will have to be 
maintained which will cause compatibility and configuration 
problems for whoever is responsible for maintenance. [It 
will be akin to tampering with and attempting to implement 
two concurrent, completely different operating systems. 
Witness the performance degradation that takes place when 
IBM's VM orchestrates the concurrent operation of CMS and 
MVS. Eliminate VM and one of the two operating systems, and 
system performance for the single remaining operating system 
is dramatically improved. EXPAND cannot serve as the single 
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network interface "operating system.” It will result ina 
closed community which is unacceptable from an 
internetworking standpoint. In such a Situation, few 
processes discussed in the previous three chapters could be 
implemented. Concurrent implementation of two 
"internetwork' operating systems will be a software 
engineering nightmare. It will result in a lot of wasted 
software effort contrary to the principles of sound software 
engineering [Ref. 36,37,38]. 

FMSO cannot afford to get involved in Supporting two 
plans for internetwork operability. It has a hard enough 
time with its current workload. It is better to remain with 
the standard DDN protocols and forego the extra features of 
EXPAND. The whole concept of SPLICE revolves around 
standardization of interfaces and relief from different 
patchwork communications schemes currently handled by a 
myriad of hardware and software. Concurrent implementation 
of TCP/IP along with EXPAND/X.25 may bring back serious 


Gn 


configuration management problems from which the Navy Supply 


System has been trying to liberate itself. 
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APPENDIX A 
COMMERCIAL PACKET SWITCHING INTERNETWORKING METHODOLOGY 


In view of the DDN mandate cited in Chapter II, it 1s 
assumed that the DDN will be the backbone of the SPLICE wide 
area network. For this reason, packet switching 
methodologies will be emphasized herein. Other major long 
haul data communications methodologies include use of dial 
up telephone lines, dedicated lines, commercial packet 
Switched networks such as Tymnet or GTE Telenet, or a 
combination of these options. A question that remains to be 
answered is which sets of protocols and methodologies will 


be used to implement this wide area data communications. 


A. DATA COMMUNICATIONS SWITCHING METHODOLOGY 


Data communications is basically broken down into three 


different methodologies of transmission. 
i Glmeuit Switching 


Circuit switching is in all practicality the same 
type of connection that is made by two individuals when 
talking on the telephone. Physical resources in time, 
Space, or frequency spectrum are dedicated to the exclusive 
meenwot a single call for the duration of that call [Ref. 4: 
p. 2/7]. Different switches connected to each other 
throughout the network create what is logically and for the 
most part physically equivalent to a twisted wire pair 
Connection. The advantage to such a connection is that, as 
Eemeedswene 15 willing to pay for and support the 
Pommection, it is at the user s disposal with no 


interference from other users contending for the line. Of 
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course the disadvantage to such a system in 
computer-to-computer communications is the cost of doing 
this over long distance. Imagine the cost of a continuous 
computer-to-computer telephone connection between Boston and 
San Francisco, 24 hours a day. In the absence of constant 
traffic over such a connection, it would quickly become 
economically prohibitive for all but the most critical 
Situations. Of course the uSers or operating systems of two 
computers always have the option of dialing up the 
connection when the operating system of one of the computers 
has a need to communicate with its distant counterpart. But 
then line contention could be a problem, quality of the 
connection may be suspect, and a dialup delay may be deemed 
unacceptable for the application in question. This is an 
oversimplification of circuit switching methodology, bxttrueen 
the purposes of this discussion it is a traditional 
telephone connection with a physical end-to-end hard wire 
linkage. Information is transferred with negligible delay. 
A short but more formal definition is offered, A former 
Switched network that provides an end-to-end path between 
user endpoints under the control of network switches" 

[Ref. 4: "py 35615 


2. Message Switching 


In message Switching, each Switch in the 
transmission path of a message successively stores the 
transmitted message in its entirety. Messages are stored on 
a permanent medium such as magnetic tape or magnetic disk 
for a specified duration of time, typically om the orderwen 
one month. If the connection to the next Switch is open and 
the line is not busy, then the message will be forwarded 
down the line. If the next connectien is busy or down, the 
message is delayed. When an appropriate connection path is 


free, the message will be forwarded to the next switch in 
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the system enroute to final destination. All intermediate 
Switches that a message passes through hold a permanent copy 
of that message on file. Thus, message switching is 


"store and forward" system. The 


commonly referred to as a 
System works very much like a TWX, Western Union telegram or 
Naval message. In fact, these systems incorporate message 
Switching technology. This type of transmission is very 
economical. Message switching can use much narrower 
transmission bandwidths than voice communications, so 
accurate transmission is possible on poor quality 
Semmunications circuits [Ref. 4: pp. 28, 29]. 

Since each message must be transmitted in entirety, 
long messages in the system can and often do block 
transmission of other shorter messages. Thus it is not an 
ideal system for real time, interactive or time sensitive 
Semmunication. From a military security point of view, it 
has the unattractive feature that an entire message iS 
Stored at several intermediate switches between the sender 
and the receiver. Thus the entire message contents are 


Subject to compromise. 
3. Packet Switching 


Packet switching 1S a Special case of message 
switching. The maximum message length is severely 
restricted, so you don't have the blocking problem that 
large messages may cause in a traditional message switched 
network. The packets move through the network, working 
their way toward their final destination on a hold and 
forward basis. Each switching center holds the packet 
temporarily until it is Sure that the next switch down the 
line properly received the packet. Unlike message 
Switching, no permanent record of the transaction is held. 
When the sending switch has confirmation of packet receipt 


from the receiving Switch, the sending switch is free to 
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dispose of the packet. Packet switching has most of the 
advantages of a message switched network. In addition, long 
messages and short messages do not interfere with each 
other, thus providing rapid and efficient throughput except 
under extreme overload conditions. Therefore, it can be 
used in an real time, interactive or time sensitive 
environment. One of the greatest advantages to packet 
Switching, in addition to its speed, is its flexibility. 

The packets do not have to follow a prespecified path to 
their destination. Their routing can be adapted between 
Switches in the system depending upon traffic load patterns. 
Packets can be routed around switch failures in the system. 
In most cases, neither the Sender, nor the receiver need be 
concerned with individual switch failures. To achieve this 
flexibility, adaptability and speed, many small Switches and 
processors (computers) must be implemented. This in turn 
requires complex routing and control procedures. The packet 
Switched network has rapidly emerged as the long haul data 
communications network of choice. It is the subject and 
folindation for this resea re mee tion tml homuemncn 

pp. 204 57 eee | 


B. PACKET SWITCHING ALTERNATIVES 


In Chapter II, packet switching was introduced. What 
follows is a discussion of two different implementation 


schemes for packet Switching. 


1. Datagram Approach 


The network treats each packet independently in the 
datagram approach. Suppose that a file is to be sent from a. 
host in Boston to a host inesan Francisco. Let us further 
suppose that this file is of such a size that it will be 


divided into 5 packets. The packets will be transmitted 


90 


from Boston in sequence: 1, 2, 3, 4, 5. However, the 
routing of an individual packet once it reaches the first 
mode Or Switch’ is independent of the routing for other 
packets comprising the file being transferred. Each switch 
in the system makes a decision as to how best to route an 
individual packet toward its final destination. Typically, 
these routing decisions are made on the basis of some 
optimum routing algorithm which changes dynamically 
according to the overall status of the network. So for 
packet 1 to traverse the distance from a host in Boston to a 
host in San Francisco, it may travel by way of a node in New 
York City, then Atlanta, then Dallas, then Denver, and 
finally San Francisco. Packet 2 may travel by way of 
Sntedaeso, then St. Louis, then Salt Lake City, and finally 
San Francisco. When the network is heavily loaded between 
two switches, or if a switch is detected to be dead, there 
are reasons for routing a packet on what may seem a 
circuitous route. If the Chicago switch is overloaded, 
there is reason for routing packet 1 to New York City and 
Melanta. The algorithm that a switch employs for optimum 
routing of packets does not concern us. What is important 
to remember is that as a result of this method of 
transmisSion, packets are likely to arrive at the San 
Francisco host out of sequence. Their arrival sequence 
might be: 1, 3, 5, 2, 4. Thus it becomes necessary to 
reassemble the arriving packets properly in order to 
recreate the file transmitted from Boston. 

The information contained in each datagram is useful 
by itself to the end user. It does not depend on the 
contents of preceding or following datagrams in order to be 
PEmGdiiaty to the destination hast [Ref: 4: pp. 117, 121]. 
Each datagram is fully identified as-~to destination and 
Sequence number within a transmission. One major advantage 


Sieeaerdatarpram approach 1s that there is mo need for call 


ofall 


set up. If a host needs to send only one or a few packets, 
datagram delivery will be quicker than the virtual circuit 
approach f[Ref. 8: pp. 31, 32]. Secondly ~ singesdatrac nam 
Service 1S more primitive, it is more flexible. Finally, 
datagram delivery 1S more reliable. If a switch in the 
normal path of routing fails, the neighboring switches 
Simply route packets around the failed switch. Of course, 
an obvious disadvantage to datagram service is the 
requirement for the receiving host to successfully 
reassemble packets that are out of Sequence and obtain 


retransmission of missing packets. 
2. Virtual Cireuit Apprecen 


In virtual circuit service, a logical connectiom 
between Boston and San Francisco would be set up before 
transmission of any packets. The Boston host would 
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initially send a "call request” to the San Francisco host. 
The call request might be routed first to Cleveland, then to 
St. Paul, then to Spokane, and finally to San Framncisecoume. 
virtual circuit has now been established. For the duraeigg 
of this connection all packets will travel by way of 
Cleveland, St. Paul, and Spokane. Any packets or 
acknowledgements transmitted from San Francisco to Boston 
will travel the reverse route. The important point to 
remember is that once the call request is established, the 
route for all subsequent packets is fixed. | 


Each packet contains a virtual circuit identifier as 


well as data. The switches need not make any decisions in 
routing. The virtual circuit route is programmed into 
applicable switches for the duration of the connection. The 


virtual circuit facilities may have the capability of 
offering “sequencing,” “error contro? “and Elowsecomterciees 
The word "may" is emphasized here because not all virtual 


circuit facilities provide these services completely 
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metiably [Reft. 8: pp. 32, 33]. “Sequencing refers to the 
fact that since the packets all travel on the same route, 
they all arrive in the sequence that they were transmitted. 
Biecor control is a service that ensures that packets not 
only arrive in Sequence but that they arrive correctly. 
"Flow control" is a mechanism to ensure that the sender does 
not overwhelm the receiver with data. If the San Francisco 
host perceives that it cannot process incoming data fast 
enough and is in danger of running out of buffer space, then 
it can send a control packet back to the Boston host 
requesting that it suspend transmission. Long meSsages are 
handled better by virtual circuit Service. The reason for 
this is that there is a constant flow of data, and the 


Switches do not have the processing overhead of deciding 


where to route each packet. It has already been programmed 
into the switches. A clear disadvantage of virtual circuit 
Switching is that there 1s no redundancy. If one of the 


Switches in the virtual circuit route becomes congested or 
goes out of commission, the entire connection 18 lost. For 
this reason, datagram service 1S employed by DDN for reasons 


of redundancy and graceful degradation. 


C. ISO (INTERNATIONAL STANDARDS ORGANIZATION) OSI (OPEN 
SYSTEMS INTERCONNECTION) MODEL 


It has become clear that the one time special purpose 
approach to communications software development is 
prohibitively expensive. One solution is to ensure that all 
hardware 1S procured from a single vendor who can deliver 
Some assurance of compatibility. Different vendors use 
different data formats and data exchange conventions. The 
software development effort becomes a nightmare when dealing 
with heterogeneous vendors and even between different model 


lines of a single vendor. 
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Hence the pressure for developing industry standards for 
data communications and networking. The benefits of such 
Standards are twofold. If standards become commonly 
accepted and implemented, vendors would be motivated to 
implement such standards in their product line. Failure to 
do so would risk loss of business to Competition thae aie 
implement standards. Customers would be in a position to 
demand the standards for equipment that they intend to buy, 
greatly simplifying their procurement, hardware 
implementation, and software development problems. One 
standard to cover this broad field is insutficient. (ism 
result, in 1977 the ISO (International Standards 
Organization) established a subcommittee that developed an 
OSI (Open Systems Interconnection) model. This model 
establishes 7 layered standards for linking heterogeneous 
computers together. These layers must coexist as mirror 
images in two computers that communicate with each other. 
Each of the 7 layers in one host communicates with its 
mirrored or "peer" layer in the second host. This peer 
communication is ruled by a set of conventions known as 
"protocol." Key elements of protocol include “syntax,” 
"semantics' and "timing." Syntax refers to such things as 
format of data and levels of signaling. Semantics refers to 
control information for error handling. Timing refers to 
Synchronization of speed and sequence control. 

These 7 layers are hierarchical in nature. If host A 
invokes the layer 7 protocol to transmit information on a 
process occurring between host A and host B, it is necessary 
for layer 7 at host A to communicate with its peer layer 7 
resident at host B. In order to effect this communication, 
the services of every layer beneath layer 7 are required in 
a downward cascading fashion. Layer~/7 in host A requests 
the services of layer 6, which in turn requests the services 


of layer 5, ...and so on down to layer ee ecame einer iie 
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Services of layer 1. The physical connection is effected 
between host A and host B through layer 1. The process of 
peer level communication then cascades upward as information 
transmitted to layer 1 in host B feeds information up to 
layer 7. These 7 ISO OSI layers are discussed below. 
Stallings does an excellent job discussing these protocols, 
and the following discussion draws heavily from his book 
ieete as: pp. 36 thru 60]. 


1. Physical Layer 


This layer covers the conventions of physical 
interfacing and the rules by which bits of data are passed 
between two machines. By physical interface we refer to the 
pin connections, electrical voltage levels, and signal 
mormats [Ref. 4: p. 109]. This layer has 4 important 
mmeeacterisiics [Ref. 39]: “electrical,” "mechanical," 
“functional, and "“procedural.'' The most common standard 
associated with layer 1 is the RS-232-C standard which 
Specifies a standard 25 pin connector among other things. 
.Also associated with the physical layer are the RS-449 
standard, and the CCITT X.21 standard. 


2. Data Link Layer 


Layer 2 iS concerned with making reliable the raw 

bit stream service and physical link specified by layer l. 
It provides the means for activating, maintaining, and 
deactivating the link. It concerns Sending blocks of data 
called "frames" with a checksum for error detection and 
enforcing frame acknowledgement. These bit oriented 
protocols are intended to provide: 

¢ Code independent operation and transparency. 

¢e Adaptability to various applications, configurations, 

and uses in a consistent manner such as point to point, 


multidrop, and loop configuration. 


* Both_two way alternate (half-duplex) and two way 
Simultaneous (full-duplex) data transfer. 
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* High Efrfiieieneye 
¢ High Reliability. 


3. Network Layer 


The concept of a protocol begins to become hazy at 
the network layer. It is designed to facilitate 
communications between systems through a data communications 
network. It is supposed to provide transparent transmission 
of data between two transport entities. At a bare minimun, 
the network layer is to relieve the transport layer above it 
of the need to know anything about the underlying 
communications medium that it is using. The network layer 
is most commonly used to handle the details of a packet 
Switched network. <A special case of the network layer is 
the CCITT X.25 protocol which will be discussed shortly. In 
a robust implementation, the network level could provide the 
capability for two devices that are not even connected 
together on the same network to communicate with each other 
through one or more intermediate networks. The network 
layer provides the capability for datagram or yvitedat 
circuit transmission of packets. It is. responsible for 


routing and congestion control. 


4. Transport Layer 


The transport layer has responsibility for ensuring 
that sequences of data are delivered error free, in proper 
Sequence, and with no losses or duplication of data. If a 
reliable layer 3 (network layer) is implemented that 
delivers reliable virtual circuit transmission, then a 
minimal implementation of the transport layer is required. 
If layer 3 supports datagrams, or is unreliable, then a 
robust implementation of the transport layer is required. 
The transport layer must provide extensive error detection, 


recovery procedures, and flow control if the underlying 


96 


network layer does not provide any one of these functions. 
It should be noted that layers 4 through 7 are generally 


referred to as the higher layers. 
5. Session Layer 


The session layer provides the mechanism for 
controlling dialogue between two presentation (layer 6) 
entities. It provides a means for the two layer 6 entities 
to establish and use a connection. This connection is. 
called a session. A sSesSSion layer may be two-way 
Simultaneous (full duplex), two-way alternate (half duplex), 
or one-way (simplex). The presentation layer may require 
that data not be transmitted until a certain quantum of data 
(quarantine unit) has accumulated. The session layer 
provides that capability of blocking the data for the 
presentation layer. It also provides a checkpointing 
mechanism, so that if a failure occurs between two 
checkpoints, the session layer iS capable of recovering the 
dialog between two presentation entities through 


retransmission of all data since the last checkpoint. 
6. Presentation Layer 


The presentation layer performs transformations on 
data in order to provide a standardized application 
interface and common communications services. It provides 
code and character set translation and the reformatting of 
data. It allows for the initial selection and subsequent 
modifications of transformations used. Typical examples of 
presentation layer protocols are text compression, 


Saeryptlon, and virtual terminal protocol. 


7. Application Layer ; 


The application layer consists of those programs 


which are designed to be run in a distributed environment. 
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Typical applications layer programs would be utility 
programs that Support distributed processing such as 
electronic mail, a transaction server program, file transfer 
protocol, and a job control language protocol. These 
programs would in turn be implemented by different 


applications for execution in a distributed environment. 


D. CCITT (CONSULTATIVE COMMITTEE FOR INTERNATIONAL 
TELEPHONE AND TELEGRAPH) STANDARDS 


Through strong leadership and participation by Great 
Britain, France, Canada, and the United States, two 
important standards for packet switching have been developed 
by the CCITT (Consultative Committee for International 
Telephone and Telegraph). These two standards are the X.25 
standard for network user interface and the X./75 standard 


for network EQ nekwerk Imteriacce 
lL. Detrnwetons 


a. DTE (Data Terminal Equipment ) 


= 


A DTE is a device, usually belonging to a data 
communications user, which provides functional and 
electrical interface to the communications medium. Typical 
examples are a teleprinter, CRT (Cathode Ray Tube) terminal, 


or a computer [Ref. 4: p. 357]. 
b. DCE (Data Circuit-Terminating Equipment ) 


DCEs are network owned devices that provide an 
attachment point for users into the network [Ref. 8: 
Poe |% 


c. Gateway 


~ 


A gateway is a device that connects two network 


systems, especially if the systems use differing protocols. 
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A gateway 1S needed to connect two local area networks, or. 
to connect a local area network into a long haul network 
beet. 8: p. 353]. 


ale Cakanet 


A catanet is a collection of packet switched 
networks that are connected together by gateways [Ref. 8: 
eee OZ]. 


me X.259 Standard 


The X.25 standard is a special case of the ISO OSI 
meotocol layers 1 through 3. More specifically, it is a 
Sedtaard tor interface between a DTE and a DCE. Rosner does 
an excellent job describing the X.25 standard. The 
mollowing discussion draws heavily from his work [Ref. 4: 
ep. 123 thru 139]. X.25 makes extensive use of existing 
Standards. Because virtual circuits are set up, and packets 
are transmitted between two DTES, it also has aspects of a 
DTE to DTE protocol. However, X.25 is generally thought of 
as a protocol with local Significance providing the DTE and 
DCE interface. In general, K.25 does not guarantee reliable 
end-to-end (DTE to DTE) transmission, nor does it guarantee 
flow control. Depending upon implementation however, it can 
and does provide those services. The X.25 standard was 
Sraetonally ratified in 1976 and has been continuously 
upgraded over the next several years. In the original and 
most prevalent implementation, X.25 provides virtual circuit 


Switching. 
a. Level 1, Physical Layer 


At this layer, the CCITT X.26 or equivalent 
American EIA (Electronic Industries Association) RS-423 
Standards define the interface for electrically unbalanced 
connections. The CCITT X.27 and equivalent EIA RS-422 
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Standards define the interface for electrically balanced 
connections. Level 1 of the X.25 provides for 


synchronization between the DTE and DCE. 
b. Level 2, Data Link Layer 


At this layer, X.25 specifies existing standards 
for link control procedures. The uSers are presumed to be 
interfacing with the network using a relatively high speed, 
synchronous data link control. Long standing standards in 
this area exist. These are the ISO HDLC (High Level Data 
Link Control) protocol and the ANSI (American National 
Standards Institute) ADGCP (Advameca Data Communrece rome 
Control Procedure). These protocols involve the use of bit 
Synchronous transmission of discrete blocks of data. A 
standard level 2 feature of X.25 is the error control 
mechanism. Errors ina bit stream are detected and 
corrected by an algorithm called CRC (Cyclic Redundancy 
Check) for error detection and block retransmission. The 
CRC algorithm takes the bits transmitted in the "frame 
address,’ “control,” and “information fields and divices 
this long binary number by another standard binary number. 
The result of course leaves you with a quotient and a 
remainder. The remainder is the critical number that is the 
CRC for that packet. This CRC is computed before 
transmission of the packet and is included in the CRC field. 
At the packet destination, the CRC is computed again and 
compared with the CRC value transmitted by the sender. If 
they differ, then an error is detected and retransmission 
procedures are initiated. Level 2 of the X.25 provides for 
error detection, correction through retransmission, and 


transparent connection between the DTE and DCE. 


—_ 
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c. Layer 3, Network Layer 


X.25 networks must insure high probability of 
Successful transmission. This generally requires alternate 
routing and congestion control procedures. The network side 
of level 3 must provide for delivery of packets in proper 
Sequence and accounting for delivery of packets. This level 
provides for switching functions permitting multiple 
connections between different combinations of network ports. 

The most popular implementation of X.25 is the 
virtual circuit implementation alluded to earlier. X.25 has 
been expanded recently to encompass standards for datagram 
transmission methodology. However, datagram implementation 
has yet to gain acceptance for commercial uSe. 

The permanent virtual circuit implementation 
guarantees connection on demand between a fixed pair of 
network endpoints. Since all data travels the same circuit 
between the same two endpoints, there is no need to specify 
the destination of a packet. This type of implementation 
though not flexible, is efficient since there is no call 
miiciation and connection delay. The two major X.25 packet 
Structures are briefly illustrated below. 

The Call Request packet fields are formatted as 
follows: 

°e Flag (8 bits): 01111110, beginning of packet 


¢ Link Address (8 bits): local DTE - DCE connection 
address 


mink CGentrol (8 ebits): used for DIE - DCE error 
eont ro) 


¢ Format Identifier (4 bits): defines type of packet to 
follow 


* Logical Channel Identifier (12 bits): connection 
identification number 


° Packet sige (S=plesi. Gebinesmrunctionm and content of 
this packet : 


* Calling Address Length (4 bits): length in digits of 
sending address 
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¢ Called Address Length (4 bits): length in digits of 
receiving address 


¢ Called Address (up to 60 bits) 
¢ Calling Address (up to 60 bits) 


¢ Facilities he (6 bits): length in 8 bit bytes of 
following fiel 


* Facilities Field up ae 512 bits): specifies use cm 
optional network facilities 


¢ Protocol Identifier (32 bits): specifies user level 
Protocols 


e User Data (up to 96 bits): user data, such as password 


e CRC (pielee Redundancy Check): error checking hashing 
algorithm 


* Flag (8 bits): 01111110, end of packet 
The Data Transfer packet fields are formatted as 
follows: 
° Flag (8 bits): OLLIITIOY beginntiremotepac ee 
« Link Address (8 bits): local DIE V=38CE connection 


address 
* Link Control (8 bits): used for DIE = Dee erm. 

EON CLO 
¢ Format Identifier (4 bits): indicates a data packet 
¢ Logical Channel Identifier (12 bits): connection 


Tdentifieattom Mumpet 


¢ Send Packet Seger Number (3 or 7 bits): sequential 
number asSigned to this packet 


* Receive Packet Sequence Number (7 bits): sequential 
number acknowledging the last successfully received 
packet from the other user 


¢* More Data ee bit): O if not prepared to receive 
more data, 1 if clear to receive more data 


¢ User Data Field ee to 1024 bits): actual data, upiee 
128 characters or bytes 


¢ CRC (Oye tae Redundancy Check): error checking hashing 
algorithm 


« Flag (8 bits): ~O1111110, end sof packet 
The two packet structures cited above are the 
basic architecture upon which all of the other varieties of 
packets in X.25 are generated. Such-packets include call 
clear, call reset, connection confirmed, packet 


acknowledgement, as well as others. As stated earlier, 
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almost all commercial X.25 implementations are virtual 
circuit connections. In order to assure proper sequence of 
delivery, the transmitting user must insert the sequence 
number into each packet. 

Additional standards designated X.28 and X.29 
have been developed to provide point to point connection 
transparency for nonintelligent or dumb terminals through a 
packet switched network. Such interface features are 
implemented by the network switching centers which must 
perform PAD (packet assembly disassembly) functions for the 
dumb terminals. 

In the virtual circuit implementation of X.25, 
flow control is accomplished through the use of a windowing 
technique. In X.25, the window flow control matches the 
rate of data transmitted by the sender into the network to 
the rate of data delivered to the receiver by the network. 
The window defines the maximum allowable number of packets 
in transit through the network in one direction for a given 
connection. It is linked and computed through the uSe of 
the current "Send Packet Sequence Number” and the last 
acknowledged packet. The concept of windowing is explained 
in greater detail in the section on TCP (Transmission 
Control Protocol) in Appendix B. 

Flow control is implemented between two uSers, 
or DTES, connected through their respective DCE connections. 
However, it is also necessary to transmit signals such as 
interrupt packets, reset requests, restart requests, and 
Status inquiries into the network. These are called "Out of 
Band" signals. Since the timing of these signals is 
critical to the connection in progress, they are not subject 
to flow control constraints that apply to other normal 
packets. i 
In conclusion, it must be emphasized that the 


hz protocol is Strictly a DTE - DCE network interface 
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protocol. It does not provide for any of the higher level 
protocols. The X.25 does offer a solution for 
implementation of higher level user-to-user protocols. It 
does this by facilitating the layering of the user-to-user 
higher level protocols on top of the 3 layers implemented by 
X.25. This makes the higher levels independent of the 


interfacing of the network. 


Bye 


lP< 


./5 Standard 


The X.75 standard is a supplement to the X.25. 
CCITT developed it for use between public X.25 networks. It 
is not likely to be used or even allowed as an interface 
between public and private networks. It does allow 
interconnection of a collection of X.25 networks in catanet 
fashion. The following discussion of the X.75 standard 
draws heavily from Stallings’ work [Ref. 8: 
pp. 302; 303, 311 thre 314]. DPhte X27 Semeehodmat 
internetworking is a network by network DCE architecture. 
It specifies a protocol for the exchange of packets between 
networks that allow a series of X.25 intranetwork virtual 
circuits to be strung together. xX./75 uses the DCE as a 
gateway, and the gateways must maintain state information 
about all virtual circuits passing through them. The 
routing of course is fixed, sinee virtual crreuits are 
implemented, and all interconnected networks must be X.25. 

X.75 specifies STE (Signal Terminating Equipment ), 
which act as DCE level gateways connecting two X.25 
networks. The interconnection of X.25 networks via X./5 
provides for DTE - DTE virtual elreult switching.) Liisi 
accomplished through the concatenation of a series of 
virtual circuits. The system is illustrated by Figure A.l 
with one STE serving as a direct gateway between two X.25 
networks, or more than one STE serving as gateways between 


intermediate X.25 networks also. 
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Each network section, depicted above as "net 1" and "net 2" 
are distinct entities with Separate virtual circuits, flow 
control, and error Gomtrol. AS far asSm@ene Dilbseare 
concerned, the entire system 1S transparent and appears as 
an enlarged X.25 network, rather than an interconnection of 
different networks. There is no encapsulation of data by 
the STEs. The same layer 3 header formats used by X.25 are 
reused. There is no end-to-end protocol. All information 
has local significance only, just as with XX, 25 (prococalm 
Because of the 12 bit "Logical Channel Identifier" field in 
the X.25 header, the maximum number of connections that an 
STE - STE internet link can handle is 4096. The X.75 
control packet format differs from X.25 only in the addition 
of a "Network Utilities Field," which is used to set up an 


STE - STE virtual circuit connection. 
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APPENDIX B 
ARPANET AND DDN PACKET SWITCHING INTERNETWORKING METHODOLOGY 


The DDN protocol suite provides an interoperable set of 
Subscriber services. In the research community, all 
subscribers have already implemented the complete protocol 
Suite. The DDN subscriber community iS growing rather 
quickly as existing and new data communications applications 
are being added to the system. At this time, not all of 
these applications in the military community have 
implemented the DDN protocol Suite. However, it is 
incumbent on all subscribers to implement the full DDN 
protocol suite in a timely manner. The Internet Protocol 
and Transmission Control Protocol are the foundation of all 
internetwork data communications through the DDN [Ref. 14: 
p. 3]. Together, these protocols deliver highly reliable 


end-to-end datagram internetwork communications. 


ewe «LP (INTERNET PROTOCOL) 


1. Background 


The Internet Protocol is designed for uSe in 
interconnected systems of packet switched data 
communications networks, otherwise known as catanets. It 
provides for transmission of long blocks of data in the form 
of datagrams. The sources and destinations are hosts 
identified by fixed length addresses. The IP provides for 
addressing, and if necessary, fragmentation and reassembly 
Sie lone datagrams for transmission through ‘small packet” 
networks. "Small packet" refers to the fact that maximum 
allowable packet size in a network is severely restricted, 


thus requiring larger packets that could pass through other 
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networks to be split one or more times into smaller packets 
that can pass through the "small packet" network. The 
following discussion of the IP draws heavily from the 
Internet Protocol specification [Ref. 32]. 

The IP is Specifically limited in scope. There are 
no provisions to augment end-to-end data reliability, flow 
control, Sequencing, or other Services commonly found in 
host to host protocols. This protocol is called on by host 
to host protocols in an internetwork environment. IP in 
turn calls on local network protocols ere txansmie, ene 


internet datagram to the next gateway, or destination host. 


2. Openraision 


The IP performs two basic functions, addressinegwene 
fragmentation. Internet modules uSe the addresses carried 
in the internet header to transmit datagrams toward their 
final destination. The internet modules use fields in the 
internet header to fragment and reassemble internet 
datagrams when necessary’for transmission through small 
packet networks. The internet module resides in each host 
engaged in internetwork communications and each gateway that 
connects two or more networks. These modules share common 
protocols for interpreting address fields, fragmentation of 
packets, and reassembly of packets. These modules, 
especially in gateways, execute procedures for making 
routing decisions as well as other functions. 

Each datagram is treated as an independent entity 
totally unrelated to any other datagram in the network. 
There iS no virtual circuit. Nor does the internet protocol 
provide a reliable communication facility. There are no 
acknowledgements either end-to-end, or hop by hop. There is 
no error control for the data, only a header checksum. 

There is no flow control, and there are no retransmisSions. 


Errors detected are reported through the ICMP (Internet 
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Control Message Protocol) [Ref. 33], which is implemented as 
part of the IP module. The IP uses four key mechanisms to 


provide its service. These are described below. 
a. Type of Service 


The type of service mechanism uses a generalized 
set of parameters that define service choices offered by the 
networks that make up the internet. It is used by gateways 
to determine what set of parameters to invoke for a 
particular network and what network to select for the next 


hop, or the next gateway when routing an internet datagram. 
b. Time to Live 


This iS a parameter that Specifies the maximum 
amount of time that an internet datagram is allowed to exist 
Within the internet. It is set by the sender and is 
decremented by every Switch that it passes through. If the 


time to live reaches zero, the datagram is destroyed. 
Ga Options 


Somlenms Paovide forecomeral Pinctions useful or 
needed in certain circumstances, but not necessary in most 
common communications. They include provisions for 


timestamps, Security, and Special routing. 
d. Header Checksum 


This provides verification that the information 
in the header that is used in processing the internet 
datagram has been transmitted correctly. The data may 
contain errors, but this checksum will not detect it. If 
the entity processing the datagram .computes a checksum that 
is not in agreement with the transmitted header checksum, 


the datagram is discarded immediately. 


LO 


3. Relationship With Other Protocols 


Figure B.1l illustrates the place of the IP in 
relation to the protocol hierarchy and scheme for host and 
terminal interoperability. The higher level protocol TCP 
(Transmission Control Protocol) intertaces swathes et com 
above and is layered on top of IP. IP is layered on top of 
one of the two network access protocols, either the ARPANET 
1822 Access Protocol, or the DDN Standard XJ72Z5  Srotcocol™ 
The DDN Standard X.25 currently under development is an 
adaptation of the CCITT X.25 Standard. It is expected to be 
implemented in the near future. In the interim, DDN Basic 
X.25 offers interoperability with other usemsegusine eon 
Basic X.25. Eventually DDN Basic X.25 Service is to be 
phased out some time after DDN Standard X.25 is implemented. 


4. Model of Operation 


The following scenario illustrates the transmission 
of a datagram from one application process to another. [In 
this scenario, illustrated by Figure B.2, we will go through 
two networks, and cross one intermediate gateway. The 
Sending application program prepares its data and calls on 
its own Internet Module to prepare for transmission of a 
datagram. The Sending Host Application passes the 
“destination address'' and other parameters as part of the 
call. The Internet Module resident in the Sending Host 
builds the datagram header and attaches the data to it. The 
Internet Module determines a local network destination 
address for this internet, Local Network 1. In this case, 
it is the address of a gateway. It sends this datagram and 
the local network address to the Local Network Interface 
(LNI-1). The Local Network Interface (LNI-1) serving the 
Sending Host, creates a local network header, and attaches 
the datagram to it. It then transmits this datagram via 
Local Network 1. 
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The datagram arrives at a Gateway Host wrapped in 
the local network header. The Local Network Interface . 
(LNI-1) for Local Network 1, strips off the datagram header 
and turns it over to the Internet Module resident in the 
Gateway Host. The Internet Module determines from the 
internet address, that the datagram is to be forwarded to 
another host in a second network. The Internet Module then 
determines a Local Network 2 address for the Destination 
Mest. iit calls the Local Network Interface (LNI-2) for 
Local Network 2 to send the datagram to the Destination 
Host. This Local Network Interface (LNI-2) builds a Local 
Network 2 header, attaches the datagram to this header, and 
transmits the datagram through Local Network 2 to the 
Destination Host. At the Destination Host, the Local 
Network Interface (LNI-2) strips off the Local Network 2 
header and passes it to the Internet Module resident at the 
Destination Host. The Internet Module determines that the 
datagram is for an application program in the Destination 
Host. It strips the datagram header, and passes the data to 
the appropriate applications program in response to a 
systems call. It also passes the source address and other 


parameters during execution of the call. 
5. Functional Description 


The purpose of the IP is to move datagrams through 
an interconnected set of networks. Internet modules reside 
in hosts and gateways in the internet system. Datagrams are 
transmitted from one internet module to another through 
individual networks based on interpretation of the internet 
address. The internet address 1S an important mechanism in 
‘the IP. When datagrams are routed from one internet module 
to another, they may need to traversé a network whose 
maximum packet size is less than the size of the datagram. 
The IP implements a fragmentation mechanism to solve this 


problem. 
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a. Internet Header Format Specifications 


A Standard internet header is illustrated in 


Figure B.3 and a brief description of the fields follows. 


Version (4 bits): Describes the format of the internet 
header. Version 4 is standard. 


THL (Internet Header Lee Ve bits): Length of the 
internet header in 32 bit words. The minimum internet 
header length is 5 (20 bytes). 


Type of Service (8 bits): This field provides an 
indication of the abstract parameters specif Bae 
quality of service desired. The parameters that can be 
specified involve precedence, delay, throughput, and 
reliability. 


Total Length (16 bits): The maximum datagram size is 
65,535 bytes. Such long datagrams are NEES E eee for 
most hosts and networks. All hosts must be 


accept datagrams of up_to 5/76 bytes. 5/6 bytes is the 
recommended default value for transmisSion o 


datagrams. 


Peeba see to 
ft 


identiviaeation (6 Sees | A unique LG GUE y Loe value 
assigned by the sender to aid in reassembling fragments 
of a datagram. 


Flags (3 Pate: Vanmousmcontrol flags, Bit O is 
reserved. Bit 1 allows/forbids fragmentation. If bit 
is set to a default of zero, fragmentation is. 
ermitted, setting it_to one forbids fragmentation. 
it 2 indicates more/last fragment. A zéro indicates 
the last fragment. A one indicates more fragments. 


Fragment Offset (he bits): This field indicates where 
in the original datagram a fragment belongs. e 

eaegment offset is measured in units of 8 bytes (64 
its 


Time to Live (8 bits): This field indicates the 
maximum length of time a datagram is allowed to exist 
in the internet system from the moment of transmission. 
This field is decremented by_1 bit every time _it. 
traverses a module that handles it. This field is 
modified in internet header processing. The intent of 
this field is to destroy datagrams that cannot be 
delivered and to give an upper bound to the maximum 
datagram lifetime. 


Peemocols(S bits): Indieatessthe next level protocol 
used in the data portion of the internet datagram. 


Header Checksum (16 bits): A checksum on the header 
only, recomputed and verified at each point the 
internet header 1s processed. 


Source Address (32 bits) 

Destination Address (32 bits) - 

Options (variable length): OVE oe eae on Mayenot 
Sees in datagrams. They must be a emented by all 


> modules (host and gateway). This field covers a 
wide variety of parameters such as security, handling 


Lies, 


restrictions, transmission ate ONES ROT E ae of 
LOU Seep specification_of routing (this is equivalent 
EO Sebeinm me a virtual circuit), stream identificatwonm 
for SATNET (Satellite Network), and internet | 
timestamps. In normal unclassified communications, 
options are not specified. 


b. Addressing 


A distinction should be made between names, 
addresses and routes. A name indicates what we seek. An 
address indicates where it is located. A route indicates 
how to get to that address. The IP is primarily concerned 
with addresses. Higher level (layer) protocols are 
responsible for mapping out a correspondence between names 
and addresses. The IP maps internet addresses to local 
network addresses. It is the task of lower level protocols 
within the local network or gateway, to map a correspondence 
between local network addresses and routes. Addresses are 
32 bits or 4 octets (bytes) in length. It begins with a 
network number, followed by the local address. There are 
three options for addressing schemes which cover the gamut 
from a large number of local networks with a small number of 
hosts, to a small number of local networks with a large 


number of hosts. 
c. Fragmentation 


It iS necessary to fragment an internet datagram 
when it originates in a network that allows a large packet 
Size and on the way to its destination must traverse a 
network with a smaller maximum packet size. An internet 
datagram can be marked "don't fragment." If it is marked 
this way, it will never be fragmented. However, if the 
datagram so marked cannot be delivered to its destination 
without fragmenting it, the datagram will be discarded. 

The IP fragmentation and reassembly procedure 


needs to be able to fragment datagrams into almost any 
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number of pieces that can later be reassembled. The 
receiver of fragments uses the datagram header 
"Identification" field to ensure that fragments of differing 
datagrams are not mixed. The "Fragment Offset" field tells 
the receiver what position the fragment held in the original 
unfragmented datagram. The "Fragment Offset" and "Total 
Length’ fields determine the portion of the original 
datagram covered by this fragment. Finally, the "More 
Fragments flag, when reset, indicates the last fragment. 
Together, the information from all of these fields is 
sufficient to reassemble a fragmented datagram. 

The "Identification" field is used to uniquely 
identify datagrams for a given connection between two hosts. 
This field must be assigned a value by the sending host when 
the datagram iS originated. It must uniquely identify that 
datagram for the maximum allowable life of the datagram on 
the internet. The "Identification," "Source Address" and 
"Destination Address" fields uniquely identify every 
datagram on the internet from all others. In addition, it 
mothe responsibility of the originating host to set the 
"More Fragments' flag and "Fragment Offset" field to zero. 

Suppose that a long datagram reaches a gateway, 
and the gateway determines that the datagram must be 
fragmented in order to reach its destination. The gateway 
will take the data portion of the original datagram and 
Split it in at least two parts. For the purpose of this 
discussion, let us assume that it will be split into two 
parts. The first portion must end on an 8 byte, or 64 bit, 
boundary. In other words, the size in bytes of the first 
portion must be divisible by 8. In fact, if there are more 
than two portions, or fragments, the length in bytes of each 
SucceSSive fragment must also be evenly divisible by 8. The 
last fragment is an exception. The last fragment need not 


end on an 8 byte boundary, but it must end on a byte 


7 


boundary. The number of 8 byte blocks of data in the first 
fragment are referred to as NFB (Number of Fragment Blocks). 
The fields that made up the internet header of the original 
datagram are copied into the internet header fields of the 
two new datagrams. The first fragment is placed in the 
first new internet datagram. The "Total Length" field of 
the internet header is is set to the length of the first new 
datagram and the "More Fragments" flag is set to l. The 
second fragment is placed in the second new internet 
datagram, and the "Total Length" field of internet header is 
set to the length of the second new datagram. In the second 
new datagram, the internet header "More Fragments" flag is 
equal to zero, the value in the original datagram internet 
header. The "Fragment Offset" field of the second new 
datagram will contain the sum of the original internet 
header "Fragment Offset" plus the NFB (Number of Fragment 
Blocks) computed earlier for the first fragment. The 
procedure described above can be generalized for a multiple 
- fragmentation Split in much the same fashion as was 
described above for the two way fragmentation split. 
Reassembly of the fragments of an internet 
datagram at a gateway or deStination host requires that the 


? 


"Identification, “Source, “Destination, wand Pmote co as 
internet header fields of the fragmented datagrams be the 
Same. This is checked by the internet module at the gateway 
or destination host. Reassembly is accomplished by placing 
the data portion of each fragment in the relative position 
indicated by the "Fragment Offset" field of the respective 
internet headers. The first fragment will have the 
"Fragment Offset" set to zero. The last fragment can be 


identified by the "More Fragments" flag being set at Zero. 


— 
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d. GGP (Gateway to Gateway Protocol) 


Gateways implement the IP so that datagrams can 
be forwarded between networks. The GGP is also implemented 
to coordinate routing and other internet control information 
[Ref. 40]. In a gateway, the higher level protocols are not 
required. The GGP as well as the ICMP (Internet Control 
Message Protocol) are added to the IP module as illustrated 
in Figure B.4. 





Figure B.4 Gateway Protocols. 


6. Implementation Remarks and ICMP (Internet Message 


Conerolmenotoco |) 


Implementation of the IP must be conservative in its 
sending behavior and liberal in its receiving behavior. It 
must be careful to send well formed datagrams, but must 
accept any datagram that it can interpret. Such an 
implementation is geared toward offering robust data 
communications service. The basic Service provides for 
fragmentation of datagrams at gateways, and reassembly being 
performed by the destination host's internet module. 
Fragmentation and reassembly of datagrams within a network 
or by private agreement between gateways of a network is 


allowed. Such fragmentation and reassembly is transparent 


poy, 


to IP and the higher level protocols, and is called "network 
dependent" or "intranet" fragmentation. Internet addresses 
distinguish sources and destinations to the host level and 
provide a protocol field as well. It is assumed that each 
protocol will provide for whatever multiplexing is necessary 
Within a host. 

An integral part of the IP is the ICMP (Internet 
Control Message Protocol) [Ref. 33]. Periodically a gateway 
or destination host will communicate with a source host to 
report errors in datagram processing. For such purposes, 
the ICMP is used. ICMP uses the basic support of IP as if 
it were a higher level protocol, but in essence, ICMP is an 
integral part of IP and must be implemented by every IP 
module. Typically, ICMP messages are sent when a datagram 
cannot reach its final destination, when a gateway does not 
have the buffering capacity to forward a datagram, and when 
the gateway can direct the host to send traffic on a shorter 
route. The purpose of ICMP is to send control messages 
about problems in the communications environment, not to 
make IP reliable. End to end reliability must be provided 
by higher level protocols if required. To avoid the 
infinite recursion of messages about messages, no ICMP 
messages are sent about ICMP messages. When dealing with 
fragmented datagram problems, .ICMP will only transmit 


messages concerning fragment zero, the last fragment. 


B. TCP (TRANSMISSION CONTROL PROTOCOL) 


The TCP (Transmission Control Protocol) was developed to 
provide highly reliable host to host communication in packet 
Switched networks, and interconnected systems of packet 
Switched networks. TCP focuses its attention on military 
computer communications requirements. It attempts to 


deliver robust service despite communication unreliability, 
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micmunmavallability in the presence of congestion. Many of 
these problems are found in the civilian and government 
sector as well. The discussion on TCP that follows draws 
heavily from DARPA's Internet Program TCP Protocol 
Specification [Ref. 34]. 


|e Tntroduct aon 


TCP is a connection oriented, end-to-end reliable 
protocol designed to fit into a layered hierarchy of 
protocols which support multinetwork applications. TCP 
provides the ability to perform reliable interprocess data 
communications between two hosts that reside on two Separate 
but interconnected networks. The major assumption is that 
TCP utilizes simple but potentially unreliable datagram 
service from lower level protocols. In principal, TCP 
Should be able to function above a wide range of 
communications systems including hard wired connections, 
packet switched networks, and circuit switched networks. 

TCP fits into a layered protocol architecture just above 
basic IP (Internet Protocol) as illustrated in Figure B.1. 
mr provides the capability for TCP to send and receive 
variable length segments of information enclosed in IP 
datagram "envelopes." The TCP specification describes an 
interface to the higher level protocols which can be 
implemented in front end processors, provided that a 
Suitable host to front end processor protocol is 
implemented. TCP is intended to provide reliable 
process-to-process data communications service ina 
multinetwork environment. It is intended to be the basis of 


host to host protocol in common use throughout the DDN. 


Cenc ecrtaces 
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Referring back to Figure B.1l, TCP interfaces from above with 


Moser Greapplication processes. From below, TCP interfaces 
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with IP. The interface between an application process and 
TCP is conducted through a set Gf calls, simimlaretorcalie 
made to the operating system for input/output Service and 
file manipulation. Calls to TCP are invoked by applications 
processes to open and close connections, and to send and 
receive data on established connections. TCP must be able 
to asynchronously communicate with application programs. 
Implementors of TCP are allowed considerable freedom. 
However, a minimum functionality is required at the TCP/user 
interface for any valid implementation. The interface 
between TCP and lower level protocols is basically 
unspecified. It is assumed that the two levels can pass 
information to each other asynchronously. Normally, the 
lower level protocol specifies this interface. TCP is 
designed to work in a very general environment of 


interconnected networks. 
3. TCP Header Format Specification 


TCP segments are sent as IP datagrams in the DDN 
implementation. The TCP header follows the internet header, 
supplying information specific to the TCP protocol. Figure 
B.5 illustrates the basic TCP header format. The various 


fields in the TCP header are briefly summarized below. 


¢ Source Port (16 bits): The source port number. 

¢ Destination Port (16 bits): The destination port 
number. 

* Sequence Number (32 bits): Sequence number assigned to 


the first data byte in this segment. 

¢ Acknowledgement Number (32 bits): The value of the | 
next sequence number that the sender of this segment is 
expecting to receive. 

°* Data Offset (4 bits): The number of 32 bit words in 
the TCP header. This indicates where the header ends 
and the data begins. 


* Reserved (6 bits): Reserved for future uSe. 
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Control Bits (6 bits): From lettGetco riche eet une 
below. 


* URG (1 bit): Unrgeme Pointer ei ictal sie eretee tae 
e ACK (1 bit): Acknowledgment field significant. 
* PSH (1 bit}ys” Push tuncticn- 

* RST (1 bit): Reset the connection. 

e SYN (1 bit): Synchronize sequence numbers. 

¢e FIN (1 bit): No more data from sender. 


Window (16 bits): The number of eae eRe ie with 
the sequence number in the Acknowledge 1eld that the 
sender of this segment is willing to accept. 


Checksum (16 bits): Checksum Sees SUS LIES threwen 
one s complement arithmetic on all 16 bit segments of 
header and text. 


Urgent Pointer (16 bits): The current value of the 
urgent pointer computed as a positive offset from the 
sequence number in this segment. Points to the 
Sequence number of the byte of data immediately 
following the urgent data. 


Options (variable): Occupy space at the end of the TCP 
header and are a multiple of bits in length. There 
are two cases for the options format. 


* Case 1: A Single byte of an option kind. 


* Case 2: A byte of Option tana ea py Ee of option 
length, and the actual option data ytes. he ome 
meaningful option implemented to date is) the lomas 

Maximum Segment Size which specifies the maximum. 
receivable segment size that the sender of the ope 
is willing to accept. This option is set once at the 
beginning of a connection. 


Padding ieee oe TCP header padding is used to 
ensure that the TCP header ends, and data begins on a 
2 bit boundary. Padding is composed of zeros. 


Operational Overview 


As stated earlier, TCP is supposed to provide 


reliable, secure logical circuit or connection service 


between a pair of processes. Providing this Service on top 


of the less reliable IP requires facilities in areas 


described below. 
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aeeebaste Data Transfer 


IGE w@aduistt = smemconktinuous Stream of bytes in 
each direction between two user processes by packaging some 
number of bytes into segment blocks for transmission through 
the internet system. The TCPs decide when to block and 
forward data at their own convenience. In Some Situations, 
the application program may want to explicitly transmit data 
at a given point, rather than letting TCP decide when to 
meamscmit data. A push’ function is provided for this 
purpose. The "push" causes TCP to immediately transmit all 


data in the transmission queue. 
bD. Re liabaslaty 


TCP must be able to recover from data that is 
damaged, duplicated, delivered out of order, or is lost by 
the internet communications system. This is accomplished 
through the assignment of a "Sequence Number" to each byte 
that is transmitted. It requires a positive acknowledgement 
(ACK) from the receiving TCP. If an acknowledgement is not 
received within a specified timeout interval, the data is 
retransmitted. The receiving TCP uses the sequence numbers 
to correctly order Segments that may be received out of 
order, and to eliminate any duplicate transmissions. 

Damaged data in the form of garbled or erroneous 
transmission is handled by adding a checksum to each Segment 
transmitted. This checksum is recomputed by the receiving 
TCP. If it is not in agreement with the transmitted 
checksum, the segment in question is discarded. As long as 
TCP continues to function and the internet does not become 
completely severed, no transmission errors will affect the 
correct delivery of data. TCP recovers from internet 


communication system errors. 


Nye 


ec.  Filow-Comt rol 


A receiving TCP Has Ene ability, cto veonrcoa leer. 
flow of data transmitted by the sending TCP. The receiving 
TCP does this by returning a "Window" with every 
acknowledgement (ACK) of segments received back to the 
sending TCP. The "Window" indicates an acceptable range of 
Segment numbers that the sending TCP may transmit beyond the 
Segment number currently acknowledged. In other words, it 
indicates an allowed number of bytes that the sending TCP 
may transmit before receiving further permission. In this 
manner, the receiving TCP can ensure that the buffer space 
allocated to the current connection does not become 
overloaded, or that data is not received faster than the 
receiving TCP can process it. This is an essential 


mechanism for asynchronously connected processes. 
d. Multiplexing 


TCP provides a set of addresses or ports within 
each host to allow several processes to conduct 
communications with a single host simultaneously. The port 
address, network address, and local host address are 
concatenated to form a socket. A pair of Sockets uniquely 
identifies each connection. A socket may be simultaneously 
used with a number of connections. The binding of ports to 
processes is handled independently by each host. It is 
useful to permanently attach frequently used Service 
oriented processes to fixed sockets and make these known to 


the public that uses them. 
e. Connections 


The reliability and flow control mechanisms 
require information which includes socket identifier, 


Sequence numbers, and window sizes to define a connection. 


MEZA. 


mae meeconnect wom 2s identified by a pair of sockets which 
identifies its two sides. When two processes wish to 
communicate, their TCPs must establish a connection. This 
mequdires the initdalization of the status information just 
described. When their communication is completed, the 
connection is terminated and the resources used by the 
connection are freed. Connections must be established 
between unreliable hosts over the unreliable internet. A 
handshake mechanism with clock based sequence numbers is 


Miao sAavorad erroneous Initialization of connections. 
f. Precedence and Security 


TCP users may specify the security and 
precedence of their communication. Default values are 


assigned when this is not specified. 


5. Details of Implementation Philosophy 


The internetwork environment consists of hosts 
connected together by a network. These networks may be 
local area networks such as ETHERNET, or wide area networks 
such as ARPANET, but in any case they are based on packet 
Switching technology. In the internetwork environment, 
these networks are connected by gateways. Processes are 
viewed as active elements of a host computer. Terminals, 
files, and other input/output devices communicate with each 
other through the use of processes. Thus all communication 


1S viewed as interprocess communication. 
a. Model of Operation 


Processes communicate with each other by calling 
on the TCP module and passing buffers of data as arguments. 
TCP wraps up this data into segments-and in turn calls on 
the internet module to transmit each segment to the 


destination host's TCP module. The receiving TCP module 
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unwraps the segment received, and passes the data to the 
receiving process through a buffer and notifies the 
receiving process. TCPs include control information in the 
Segments transmitted to ensure reliable ordered transmission 
Of @datvar 

TCP uses the internet module to provide the 
interface to the local network. The internet module wraps 
TCP segments inSide internet datagrams and routes these 
datagrams to the destination internet module or an 
intermediate gateway. To transmit the data through a local 
network, it is yet again wrapped up inside a local network 
packet. Packet switches may perform further packaging 
(wrapping), fragmentation, or other operations to deliver 
the local packet to the destination internet module. At a 
gateway between networks, the internet datagram is unwrapped 
from its local packet and examined to determine through 
which network the internet datagram should be routed next. 
The internet datagram is then wrapped up again in a packet 
established by the local protocol of the next network it is 
to travel through. It is routed through to the next 
gateway, or to the destination host, if it resides in that 
network. The internet module that serves the destination 
host reassembles the datagram if it was fragmented. It then 
unwraps the TCP segment from the datagram and passes it to 
the destination TCP module. 


b. Host Environment 


TCP is assumed to be a module in an operating 
System. Users access TCP in the same manner that they would 
access the file system. TCP needs to call on other 
operating system functions, for example, to manage data 
Structures. The actual interface to-~the network is assumed 
to be controlled by a device driver module. TCP does not 


actually interface with the device driver module. TCP 


Weer 


interfaces with the internet module (IP). The internet 
module actually calls on the device driver module. The 
functions of TCP allow implementation in a front end 
processor. However, in such a scheme a host to front end 


protocol must provide the TCP/user interface. 
c. Interfaces 


A user process makes calls on the TCP module to 
OPEN and CLOSE connections, to SEND or RECEIVE data, or to 
obtain STATUS about a connection. The TCP/IP interface 
provides for calls to send and receive datagrams addressed 
to TCP modules resident in hosts anywhere in the internet 
System. These calls require parameters for passing the 
"address," "type of service," "precedence," “security,' and 
other protocol information. Figure B.1l illustrates where 
TCP lies relative to the protocol hierarchy in the DDN. It 
is expected that TCP be able to Support higher level 
protocols efficiently. It should be easy to interface TCP 
with higher level DDN protocols such as FTP (File Transfer 
Emotaecol), SMIP (Simple Mail Transfer Protocol), and TELNET 


(Network Virtual Terminal Protocol). 
d. Reliable Communication 


Transmission reliability is accomplished through 
the use of "Sequence Numbers" and "Acknowledgment Numbers." 
In concept, each byte of data transmitted is assigned a 
Sequence number. When a Segment 1S transmitted, the first 
byte of data in the segment is identified by the segment 
"Sequence Number.” Segments also contain an "Acknowledgment 
Number” which is the sequence number of the next expected 
byte to be transmitted in the reverse direction. In other 
words, it is the sequence number of the last byte received 
plus 1. When TCP transmits a segment containing data, it 


places a copy of that segment in a buffer called the 
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retransmission queue and starts a timer. The sending TCP 
waits for an acknowledgment for the Segment transmitted. If 
it receives an acknowledgment for that segment prior to 
expiration of the timer, the segment is deleted from the 
retransmission queue. If the timer expires and no 
acknowledgment iS received, then the segment is 
retransmitted, and the cycle is repeated with a copy 
remaining in the retransmission queue. An acknowledgment by 
a receiving TCP does not guarantee that the data has been 
delivered to the receiving host user process. It indicates 
that the receiving TCP module has acknowledged 
responsibility for doing so. 

A flow control mechanism is employed to regulate 
the flow of data between TCP modules. The receiving TCP 
module advertises a "Window" to the transmitting TCP module. 
It should be remembered, that two way communication is often 
effected simultaneously. So both TCP modules are 
transmitting and receiving concurrently, and thus both 
advertise a "Window’ to the opposite of the pair. The 
"Window' specifies the number of bytes, starting with the 
"Acknowledgment Number" that the receiving TCP is currently 


prepared to receive. 
e. Connection Establishment and Clearing 


Unique addresses must be available for each TCP 
module, since it will likely be serving many processes, and 
each of these processes needs to be identified. The 
internet address identifying the TCP module is concatenated 
with the port identifier to create a "socket" which is 
unique throughout all the networks connected together. A 
connection is fully specified end-to-end by a pair of 
sockets. A local socket can participate in many connections 
to different foreign sockets. Connections can Support 
transmission in both directions simultaneously (full 


duplex). 


I) 


A connection is specified in the OPEN call by 
the local port and foreign socket arguments. TCP supplies a 
Short local connection name to this connection, a nickname 
of sorts, by which the user process can refer to the 
connection in Subsequent calls. State information about a 
connection consists of several items of data. This 
@onnection state information is stored in a data structure 
iown as the TCB (Transmission Control Block) which is 
Similar in concept to the PCB (Process Control Block) that 
an operating system maintains about an executing process in 
a multiprogramming environment. The OPEN call specifies 
whether connection establishment should be actively pursued, 
or passively waited for. A passive OPEN request indicates 
Mat a process iS willing to accept incoming connection 
requests, rather than attempting to initiate a connection. 
Processes requesting passive OPENS may be willing to accept 
connection with any caller. In this case, a foreign socket 
of all zeros is used to denote an unspecified socket. 
Unspecified foreign sockets are allowed only on passive OPEN 
requests. A service process, such as a "login" procedure, 
would issue a paSSive open request with an unspecified 
foreign socket. Well known sockets are a convenient 
mechanism for associating a socket address with a standard 
Service. Such would be the case for higher level protocol 
processes such as TELNET, FTP, SMTP, and RJE (Remote Job 
Entry). 

Processes can 1Ssue passive OPENS and wait for 
matching active OPENs from foreign processes. TCP will 
inform the local process when the connection has been 
established. Two processes that isSue active OPENS to each 
other simultaneously will be correctly connected. There are 
two basic cases for handling for handling a connection 
between a local passive OPEN call and a foreign active OPEN 


call. In case 1, the local passive open call has fully 
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Specified the foreign socket, so the match must be exact. 
In case 2, any foreign Socket is acceptable as long as the 
sockets match. In between lie cases that limit connection 
to a restricted set of foreign sockets. OPEN calls are 
recorded in the TCB (Transmission Contra bloem: 

The procedure to establish a connection utilizes 
the "SYN" (Synchronize) control flag and involves an 
exchange of three messages known as a "three way handshake." 
A connection is initiated when a segment containing a "SYN" 
(Synchronize) flag rendezvous with a waiting TCB 
(Transmission Control Block) entry created by the local user 
process OPEN command. A connection is initiated when the 
local and foreign sockets match. The connection becomes 
"established" when "Sequence Numbers” have been synchronized 
in both directions. The clearing of conmecterans "2ice 
involves the exchange of segments which contain the "FIN" 


(Finish ) scomtrol palace 
ff: Data Commtniedacioms : 


Data that flows on a connection is asynchronous, 
and therefore can be thought of as a stream of bytes. Data 
flowing in a given direction is normally stored in a buffer 
of the receiving TCP module until it is filled, or reaches a 
high water mark. At this point, the data is normally 
transferred to the receiving process. The sending TCP has 
the option of specifying to the receiving TCP that data in 
the current segment, and all previous segments, should be 
transferred to the uSer process immediately. The sending 
TCP accomplishes this through settine thew Fou me oon 
control flag. This will automatically cause all buffered 
data in the receiving TCP segment to be transferred to the 
user process. This buffering process can and does occur at 
both ends of the sending process. The sending TCP can also 


wait until an appropriate amount of data is accumulated in 
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its send buffer before sending segments to the receiving 
TCP. When the user process indicates that the data should 
be "pushed," the buffer is cleared and transmitted 
immediately. Likewise, when the segment containing the 
Been tlap is) received, all data in the receive buffer is 
cleared and transferred to the receiving process. 

In addition to the "PSH" control flag, there is 
aoe URG (urgent) control flag. This indicates to the 
receiving TCP that there is urgent information in the 
current segment that should be processed immediately. The 
"Urgent Pointer" field specifies the "Sequence Number" of 


the byte immediately following the end of the urgent data. 
g@. Precedence and Security 


Precedence and security is provided for through 
use of the Internet Protocol "Type of Service" field and 


moecurity option. 


6. TCP Quiet Hayne. Ceres ae 


Sequence numbers are 32 bit fields, therefore the 
possible combinations of different Sequence numbers that can 
be assigned by a sending TCP are 2 to the 32nd power, or 
(eo? 4526/7,296 in base 10: The reason for such a wide range, 
is to attempt to limit the possibility of two segments with 
the same sequence number but different data existing in the 
internet concurrently. Even if a sending TCP were to 
continuously transmit data bytes at the rate of 2 
megabits/second, it would take approximately 4.5 hours to 
cycle through all 4,294,967,296 sequence numbers. So the 
chance of duplicate segment numbers for different data 
appears highly unlikely. At 100 megabits/second, the cycle 
time is reduced to 5.4 minutes, which is short, but still 
exceeds the internet datagram "Time to Live" upper bound of 


256. Even if it took a datagram one second to be passed 
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from one internet module to another internet module, this 
would still only allow a datagram to exist for 256 seconds, 
roughly 4.25 minutes, before it would be discarded. 

However, if the sending TCP host crashes, it may 
well present a problem. Unless the sending TCP host 
remembers the last "Sequence Number" transmitted, it is 
likely to reset the counter at some arbitrary point such as 
O. In this case, there is a distinet possibmery,  o. 
transmitting a segment with a sequence number equal to the 
Sequence number of another segment transmitted before the 
sending host crashed. Thus two segments of differing data 
but with the same sequence numbers may coexist in the 
internet. In the absence of knowledge about the sequence 
numbers used in a particular connection, the TCP 
specification recommends the sending host delay for MSL 
(Maximum Segment Lifetime) seconds before emitting segments 
on the connection. This will allow time for segments from 
the earlier connection incarnation to drain from the system. 
We can normally assume that MSL is equal to the IP "Time to 
Live" maximum of 256 seconds. If for some reason, it is 
found that conditions may exist wherein a datagram may take 
more than one second to travel from one internet module to 
the next, then the MSL must be adjusted upwards accordingly. 
Prudent “implementation of TEP,EP dictatecse thatthe ct 
brought back online deliberately delay emitting segments for 
one MSL after recovery from a crash. This is called the 
"Quiet Time" specification. Hosts which prefer to avoid 
waiting must be willing to risk possible confusion of old 
and new packets at a given destination. In a Supply and 
logistics transaction environment, failure to implement 


"Quiet Time" specification could prove disastrous. 
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AA: 
AIOK ° 
ADCCP: 


ADP: 
AIS: 
AMS 2; 
ANSI: 
eee L : 
ASO: 
Peels ; 


BBN: 
BIOT: 
BOC : 
BSC: 
Bao: 
C31: 


CAIMS: 


CAS: 
CASREP: 
CeLTT : 


eNO : 


COMNAVALRPAC: 


COMNAVLOGPAC: 


COMNAVTELCOM: 


CONUS: 
COSAL: 


APPENDIX C 
GLOSSARY OF ACRONYMS 


American Airlines 
Acknowledgement 


Advanced Dataecommunications Control 
Procedure 


Automatic Data Processing 

Automated Information System 

Aviation Structural Mechanic Second Class 
American National Standards Institute 
Allowance Parts List 

Navy Aviation Supply Office 


American Telephone & Telegraph Information 
systems 


Bolt, Baranek & Newman 

British Indian Ocean Territory 
Bell Operating Company 

Binary Synchronous Communications 
Boiler Technician Third Class 


Command, Control, Communications and 
Intelligence 


Conventional Ammunition Integrated Management 
system 


Contract Administration Service 
Casualty Report 


Consultative Committee for International 
Telephone and Telegraph Standards 


Chief of Naval Operations 


Commander, Naval Air Forces, U. S. Pacific 


leet 


Commander, Naval Logistics Command, U. S. 
Pacific Fleet 


Commander, Naval Telecommunications Command 
Contiguous United States (48 States) 


Coordinated Shipboard Allowance List 


ILS 


CPU. 
CRG: 
Chie 
CV: 
DAASO: 
DARPA: 


DBMS: 
DEA: 
DCASMA: 


DCASPRO: 


DEASK. 


DCE: 
DDG: 
DDN: 
Dibs. 
DEG: 
Die 
DLS ae 
Dew: 
DODDS: 


DSe. 
Dane 
DUSD: 
ELA: 
IZ ID). 
JS Ae S) & 
EMSOr 
Pare 
lad 
GGP: 
GS: 
GSA: 


Central Processing Unit 

Cyclic Redundancy Check 

Cathode Ray Tube | 
Aircraft Carrier (conventionally powered) 
Defense Automated Addressal Systems Office 


Department of Defense “Advanced Research 
Projects Agency 


Data Base Management System 
Defense Communications Agency 


Defense Contract Administration Services 
Management Area 


Defense Contract Administration Services 
Plant Representative Office 


Defense Contract Administration Services 
Region 


Data Circuit=- Terminating Equrpment 
Guided Missile Destroyer 

Defense Data Network 
Directory/Dictionary System 
Digital Equipment Corporation 
Defense Logistics Agency 

Defense Logistics Services Center 
Department of Defense 


De SP ome ne of Defense Intelligence 
ormation System 


Display System Protocol 

Data Terminal Equipment 

Deputy Under Secretary of Defense 
Electronic Industries Association 
Functional Description 

Federal Information Processing Standard 
Navy Fleet Material Support Office 
File Transfer Protocol 

Fiscal Year 

Gateway to Gateway Protocol 
General Schedule 


General Services Administration 
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Gile: 

FDIS : 
HSLN: 
eM: 
TEMP ; 
ECP : 

mea. ; 


IMA: 

nee: 

ie 0 ; 
SCL; 
LNI: 
MCRL: 
Ma T : 
MENITAC: 


ML-N: 
MOCAS: 


eio-DOS; 
MSL: 
My S : 
NARDAC: 
NATO: 


NAVMASSO: 


NAVSEA: 
NAVSUP: 
NBS: 
NaC : 
NIIN: 
NIR: 
NIU: 

Nik G 
NID. 
NSC: 


General Telephone & Electronics 
High Level Data Link Control 
High Speed Local Network 
International Business Machines 
Internet Control Message Protocol 
Bime mbt. COMO borne 


Institute for Computer Sciences and 
Technology 


Intermediate Maintenance Activity 

Internet Protocol 

International Standards Organization 

Job Control Language 

Local Network Interface 

Master Cross Reference Listing 
Multifunction with a Fixed number of Tasks 


smaller version of a TAC (Terminal Access 
Controller 


Management List - Navy 


Mechanization of Contract Administration 
services 


Microsoft - Disk Operating System 
Maximum Segment Length 

Multiple Virtual Systems 

Navy Regional Data Automation Center 
North Atlantic Treaty Organization 
Navy Management Systems Support Office 
Naval Sea Systems Command 

Naval Supply Systems Command 
National Bureau of Standards 

Network Information Center 

National Item Identification Number 
National Item Record 

Network Interface Unit 

National Research Council 

National Security Agency 


Naval Supply Center 
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NSD: 
NSN: 
Ose 
OS IE 
EBX. 
lal@ys 


PC-DOS: 


Gere 
Fon: 
REGS 
Rigs 
Roi 


SACDIN : 


SAMMS : 


SATNEL: 


SOLE: 
Se 
Ske: 
oMne. 
SNA: 
SNAP: 
Se lO 
Se) 
SMEa > 
SYN: 
TAG: 
else 
fhe 


MRI NT Ab 


TP-4: 
deSikes 
TWA: 
UADES . 
UG: 


Naval Supply Depot 

National Stock Number 
Operating System 

Open Systems Interconnection 
Public Branch Exchange 
Personal Computer 


Personal Computer - Disk Operating System 
(IBM) a a = ee 


Process Control Bitoek 

Public Switched Network 

Request For Comments 

Routing Identifier Code 

Remote Job Entry 

Strategic Air Command Digital Network 
Standard Automated Material Management System 
Satellite Network 

Synchronous Data Link Contre 
Storekeeper First Class 

Storekeeper Chief 

Simple Mail Transfer Prorgcor 

Systems Network Architecture 
Shipboard Nomtacttecal ADP i cocram 
Navy Ships Parts Control Center 
System Specification 

Signal Terminating Equipment 
Synchronize 

Terminal Access Controller 
Transmission Control Block 
Transmission Control “Puotecoa! 

Network Virtual Terminal Protocol 
Transmission Protocol (layer 4) 
Telecommunication Service Request 
Trans World Airlines ; 

Uniform Automated Data Processing System 


Unit Identification Code 
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URDB: User Requirements Data Base 


ie Virtual Machine 
WINCS: ; WIN Communications Subsystem 
WSF: Weapons System File 
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